Re: poor ethernet performance?
Tim Baird wrote: > I hope everyone is benefitting by these simple facts *chuckle* "Simple facts.." You sound like my physics professor. I for one am benefitting very much from the discussion. I got hired at my current job as a software person, but I have a background in hardware so I try and make it into the NOC every excuse I get (promotability, don't you know). It always helps if sound like I have a vague idea what I'm talking about. :) I just made up my first ethernet cables the other day, and learned an interesting tidbit that I'm sure is beyond elementary to most of you, but may benefit someone else. What I was told is that the reason Cat 5 cable is so much more efficient is that each of the 4 pairs of wire is twisted at a different rate. This helps reduce the possibility of frequency synchronization for the EM fields the pairs create. Soaking it in, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Devloper
Assem Salama wrote: > > I am interested in helping in the development in FreeBSD. I'm not a > hotshot programmer but I know how to program. Could someone please send > me the available projects that I can work on and some info about them? Step one, ignore all those responses to the poster who sent you the handbook page, they are trying to drag you into freebsd's latest holy war. :) Step two, that handbook page has a lot of good stuff, read it. Step three, (and I can't believe this isn't mentioned in the handbook) if there isn't anything on that page that looks interesting to you, take a look at http://www.freebsd.org/cgi/query-pr-summary.cgi and see if anything there strikes your fancy. Look first at unsassigned PR's, but if one of them that is assigned to someone looks like something you can handle and have time to work on, mail the person it's assigned to and ask them about it. Looking forward to your first patch, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Wed, 21 Jul 1999, Vincent Poy wrote: > Greetings everyone, > > What are the current good motherboards for FreeBSD for the pentium > II and III? I know on the Pentium, it was the ASUS board but for the > PII/PIII, is the Abit the better board? Also, I was wondering what is the > fastest Celeron chip that can be overclocked to run at 100Mhz FSB? Does > it matter if it's Slot 1 or PPGA based? Thanks. At work we're having good results with an Intel N440BX motherboard. It's a dual cpu board, running 2 PIII 500's like a champ. It also has the ability to redirect all console output (like boot/bios messages, etc.) to a serial console. It comes with a built in Etherexpress Pro 100+ as well. I have an Asus P2B at home that I've run my Celeron 300A overclocked to 450 since the first of the year with no problems (and BIG fans). HTH, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf leakage in NFSv3 writes, possbile?
"David E. Cross" wrote: > > Well, I just -STABLED the server to see if it fixed it, but I was certainly > running out. the server had only 3000-ish mbuf chains, and it would go > through > them all in a day. Well, have you tried increasing the number of available mbufs and see if you reach a point of stability? Assuming you have enough physical ram you could do 15k mbufs on -Stable without a problem. Check LINT for the nmbclusters option if you need help with it. Good luck, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
[Fwd: wd0 DMA errors]
No answer on -current, any help appreciated. Doug Original Message My boxes at work are -current from 7/16. They both use IDE disks since other than system stuff the disk I/O for the real work is all NFS. In the daily logs this morning I see this: > wd0: interrupt timeout (status 58 error 0) > wd0: wdtimeout() DMA status 4 Can anyone shed some light on what that is, and how bad it is? I won't have access to the box itself till monday, but it would be nice to have some answers ready when I go in. Thanks, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" 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: [Fwd: wd0 DMA errors]
Sheldon Hearn wrote: > > On Sun, 25 Jul 1999 10:59:26 MST, Doug wrote: > > > No answer on -current, any help appreciated. > > We're probably all sitting here thinking "I'm sure this was asked and > answered recently. He can read his CURRENT mail like the rest of us." I have indeed read my -current mail. Several bugs in the PCI and DMA code have been mentioned in the past week, but frankly I don't have enough expertise in either to know for sure that the bugs mentioned would produce the error messages I saw. A simple, "yes, those were the bugs fixed recently" is all that was needed. Thank you, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
Vincent Poy wrote: > > On Thu, 22 Jul 1999, Doug wrote: > > > On Wed, 21 Jul 1999, Vincent Poy wrote: > > > > > Greetings everyone, > > > > > > What are the current good motherboards for FreeBSD for the pentium > > > II and III? I know on the Pentium, it was the ASUS board but for the > > > PII/PIII, is the Abit the better board? Also, I was wondering what is the > > > fastest Celeron chip that can be overclocked to run at 100Mhz FSB? Does > > > it matter if it's Slot 1 or PPGA based? Thanks. > > > > At work we're having good results with an Intel N440BX > > motherboard. It's a dual cpu board, running 2 PIII 500's like a champ. It > > also has the ability to redirect all console output (like boot/bios > > messages, etc.) to a serial console. It comes with a built in Etherexpress > > Pro 100+ as well. > > Cool... I thought the Intel motherboards weren't that good > compared to other brands.. Hrrmm... what about them would be "not good," and how would I test it? I don't know enough about SMP hardware to know what to compare, but I do know that these are working fine for us, and at the speed the cpu's are running at I'm not sure that a few percentage points difference would be noticable. Also, the serial console option got me big points with the boss, since we have all sorts of remote console stuff set up in the office and the more that can be seen while booting a troubled box the better. > > I have an Asus P2B at home that I've run my Celeron 300A > > overclocked to 450 since the first of the year with no problems (and BIG > > fans). > > Hmmm, what kinda fans did you use and where can one get those? Is > the 300A overclocked as fast as a regular PII 450Mhz? I got the fans from the store that sold me the CPU. It's a double fan with a big heat sink in the middle. http://www.thechipmerchant.com/ should do you up. As for speed, as far as I can tell on the few benchmarks I've run, yes, it's just as fast. Some things are actually faster since the onboard cache for the 300A runs at full speed. The old celerons without cache are dogs though, even if you do overclock them. If RC5 is any indication I can do 1.2Mkeys per second when there is no other load on the system. HTH, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: wd0 DMA errors]
On Mon, 26 Jul 1999, Julian Elischer wrote: > I'm not convinced that this is the same error.. > the message is different.. *Nod* That's the other reason I wrote in about it. As soon as we get some other stuff cleared away I'm going to try building the world on those machines and see if the error resurfaces. Thanks, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
XFree 3.3.4 not on ftp.freebsd.org?
I was trying in vain today to get X 3.3.4 installed on my new system and couldn't seem to make it happen using sysinstall, even after I rebuilt it. AFAICS, there is no XFree 3.3.4 package available on ftp.freebsd.org/pub/FreeBSD, but I may have missed something. Fortunately it is on wcarchive, so I just pulled down all the bits and installed it the "hard" way, however I know I'm going to run into trouble down the road when ports start looking for the X stuff in /var/db/pkg. Any comments or suggestions welcome, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
Sheldon Hearn wrote: > > On Mon, 26 Jul 1999 21:09:50 -0400, Tim Vanderhoek wrote: > > > I seem to remember that you can get away with a simple "mkdir > > /var/db/pkg/xxx" to fake it. > > Can you think of any ports that test for the existance of XFree86 using > the package system? They use USE_X_PREFIX or USE_X_LIB, both of which > test for libX11, no? Well, in an ideal world the ports that need parts of X would only test for the parts that they need. However right after 3.2-R came out there was a flurry of -questions mail about broken pkg dependencies because sysinstall wasn't properly registering the X install. If the port depending on the existence of /var/db/pkg/X* is actually an error I'll report what I find to the -ports list. Thanks, Doug 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?
Sheldon Hearn wrote: > > On Mon, 26 Jul 1999 22:41:24 MST, Doug wrote: > > > However right after 3.2-R came out there was a flurry of -questions > > mail about broken pkg dependencies because sysinstall wasn't properly > > registering the X install. > > Is this a different problem from the broken compat22 installation? Yes. > > If the port depending on the existence of /var/db/pkg/X* is actually > > an error I'll report what I find to the -ports list. > > I'm pretty sure it constitutes "non-conformant" behaviour and I'd be > happy to look at it. Hrrmm... come to think of it, I think that the problem actually amounted to the ports not being able to register after installation was done. In other words, (IIRC) after they were built and installed ports that depended on X were unable to insert their +REQUIRED_BY entries, so this would not constitute "broken." However, I'm a bit fuzzy on it, and I'm very tired so I'm not sure. If I find anything odd I'll report it. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
On Tue, 27 Jul 1999, Jordan K. Hubbard wrote: > > the parts that they need. However right after 3.2-R came out there was a > > flurry of -questions mail about broken pkg dependencies because sysinstall > > wasn't properly registering the X install. If the port depending on the > > Just to clear up a misconception; this isn't actually a sysinstall > problem. Okey dokey. As long as y'all are aware of it I'm happy, I just hadn't seen it mentioned. Thanks for clarifying, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: VMWare plug/quickie tests.
On Tue, 27 Jul 1999, Kip Macy wrote: > Is there anyone in particular to whom we should write at VMWare? > I agree with his sentiments. I picked a likely looking name from the "contact us" page. Make sure that you only write if you are willing to pay for the product if they make it, and then be sure to tell them that if you are. When I responded to their standard "we have no plans for a freebsd port" response with some reasonable, calm information about market share, demographics, etc. the sales droid actually responded with something to the effect of, "Hmmm.. I wasn't aware of that, I'll have to pass that on." So perhaps there is hope, but I'm still not holding my breath. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On 27 Jul 1999, Dag-Erling Smorgrav wrote: > I move that we replace GNU grep in our source tree with this > implementation, once it's been reviewed by all concerned parties. First, I'm all for this idea, and applaud you and Jamie for taking it on. I do have a few questions. Does POSIX say anything about grep, and if so, is this version compliant? Also, I'd like to put in another vote for full GNU grep feature compliance, since while having our own code is a good thing, I am against introducing gratuitous differences since I have enough of those to deal with already. I think ports building is a good test, but has anyone tested it with RCS yet? IIRC RCS is heavily dependant on GNU grep, diff and patch. I don't think CVS is dependant on external programs anymore though. I use grep heavily in day to day administration tasks so I look forward to giving this a try. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Tue, 27 Jul 1999, Jamie Howard wrote: > I do not have a copy of POSIX, but I do have Unix98 which is a superset of > POSIX. Right now, excluding bugs, it is Unix 98 and therefore POSIX > compliant Good news, thanks for addressing this concern. > except for -e. -e should permit multiple patterns and it never > occured to me that anyone would want to do this. Ah, well, if the world were limited to just what I could imagine, how boring would that be? The more complete the feature set, the better off we are for my money. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Tue, 27 Jul 1999, James Howard wrote: > On Tue, 27 Jul 1999, Doug wrote: > > > Ah, well, if the world were limited to just what I could imagine, > > how boring would that be? The more complete the feature set, the better > > off we are for my money. > > You misinterpretted, I didn't know you could do that therefore I didn't > implement that. I certainly understand why you would want to :) Ah, gotcha. Even better. :) Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Tue, 27 Jul 1999, Brian F. Feldman wrote: > If it will get ALL of you to give it a rest, how about: > per-rule logging limits This has been needed for some time now. Also, please don't forget the oft-repeated request to have seperate accounting and logging counters so that you can zero one, but not the other. > logging limit raising > logging limit resetting I'd say that these are good knobs to have (I assume you're talking sysctl's?) but I'd also like to suggest a knob that allows you to toggle whether these can be changed at securelevel > 1, which knob is not resettable at securelevel > 1. I think that this would answer the needs of all parties concerned. > Which would all NOT affect the statistics? Oh good, you didn't forget. :) > I am, yes, suggesting I will implement it. Coolio. And inre the request to hear from the users of the code, I am one, have been for years, and deploy it in many different environments (including natd, basic security, etc.). These would be very welcome additions assuming that the performance hit is negligible. Thanks, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
On 26 Jul 1999, Dag-Erling Smorgrav wrote: > Sheldon Hearn writes: > > I plan to mention in the comments for each service in /etc/services, the > > latest RFC describing the service. > > Good idea. H... I'm not sure what this gets us. Wouldn't it be better to place this kind of information in the man page that you suggest below? As often as /etc/services gets read, do we really want to bloat it with non-functional information? > Don't. Instead, put it in a separate rfc(7) man page which you refer > to in the services(5) man page. Good suggestions all the way around. I'd also like to throw in this link, which is the best RFC repository I've seen on the basis of speed, reliability, and cross-indexing: http://www.cis.ohio-state.edu/hypertext/information/rfc.html. If you really want to improve /etc/services, the first commit should be to delete all the extraneous whitespace at the end of the lines. 23$ grep -c ' $' /etc/services 173 25$ grep -c '^I$' /etc/services 97 Next it would be nice if we added entries for things in our system that don't have them. (Hint: what's listening on ports 1022 and 1023?) Then, someone either needs to fix getserv*() so that they accept port ranges like 6000-6063/tcp (much preferred) or roll out those port numbers in /etc/services (yuck). It would also be nice if someone would take another look at bringing our /etc/services file more up to date with IANA (http://www.isi.edu/in-notes/iana/assignments/port-numbers). I believe someone has a PR open on this... :) David O'Brien and I were working on it for a while, but we both got busy working on other things. I had a pretty good set of scripts going to produce a workable file in services format from the IANA list, but what I should really do is write one perl script to do it. I fear however that the chance of the file being updated on that kind of scale would be very small (it always meets a lot of resistance) so I'm not sure it would be worth it. Ideas? Comments? Finally I want to urge a lot of caution to anyone who tampers with the file. I learned from painful experience that very small errors can lead to big problems in very unexpected ways. For instance, my ipfw firewall went totally nutso at one point because I had some comments in /etc/services in the wrong format back when I was playing around with it. This is not something to be tampered with lightly. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
Dominic Mitchell wrote: > > On Thu, Jul 29, 1999 at 09:04:20AM +0100, Josef Karthauser wrote: > > A question that always baffled me (I'm fairly easy to baffle) is why we've > > got some numbers defined as both udp and tcp when the service type is only > > one or the other. Does anyone know? > > Probably because the IANA specifies them that way. I think that they > try to keep both UDP and TCP ports the same, "just in case". There > might be a better explanation in rfc1700 (assigned numbers) Nope, that is the official reason. Cheesy-poofs for you. :) 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
Josef Karthauser wrote: > Ok - but it's a bit misleading having both values in /etc/services.. > > Shouldn't be: > http 80/tcpwww www-http #World Wide Web HTTP > http 80/udpwww www-http #World Wide Web HTTP > > Should be: > http 80/tcpwww www-http #World Wide Web HTTP > http 80/udp #[not used] > > Don't you think? At least that way you don't have to read all of the > rfcs to construct a firewall ;). You should probably add them both anyway, but that's beside the point. I'm not sure if adding comments like that would be worth it, however I tend to think that it is better to just leave it as is since that way if something changes in the future, we're already set. Also, "not used" might lead someone to believe that they could use that UDP port for their own little project. I suggested that we add the link to the IANA page way back when, but there are still some people that believe that our services list contains all the information they need. Doug 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, 30 Jul 1999, Nate Williams wrote: > > 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 thought we decided that the networking gurus we're going to make it > possible to send out broadcast packets on an unconfigured interface so > that DHCP would work, so that bpf wasn't required. This is by far the preferred solution. I might have the details archived from the dhcp mailing list, but IIRC it boils down to dealing properly with an address of 255.255.255.255. Whoever it was that mentioned it recently on this list clearly had the right idea. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
On Wed, 28 Jul 1999, Matthew Dillon wrote: > :> Sheldon Hearn writes: > :> > I plan to mention in the comments for each service in /etc/services, the > :> > latest RFC describing the service. > :> > :> Good idea. > : > : H... I'm not sure what this gets us. Wouldn't it be better to > :place this kind of information in the man page that you suggest below? As > :often as /etc/services gets read, do we really want to bloat it with > :non-functional information? > :... > :Doug > > I kinda like the idea of putting the RFC numbers in comments in > /etc/services. It makes the comments more meaningful. I still haven't heard anyone answer the two key (IMO) questions. Why is it better to have this in the file than in a man page, and how do you justify the additional cost to parse the file for every single system call that uses it? Please note that I _do_ think that the information is valuable. My only concern is that putting it IN the file has more costs than benefits. > It would be nice if we DBM'd /etc/services. Well that would definitely solve the problem of the "cost" of comments that I mention above, and it could also be handy in the sense that you could build an error-checker into the dbm'ing process. However this raises additional questions, like how to deal with the situation where the file is updated but the db is not. Thinking in mergemaster terms, I already have to special case master.passwd for this reason, and probably should special case login.conf too (just made myself a note). Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
On Thu, 29 Jul 1999, Ben Rosengart wrote: > On Thu, 29 Jul 1999, Josef Karthauser wrote: > > > Ok - but it's a bit misleading having both values in /etc/services.. > > > > Shouldn't be: > > http 80/tcpwww www-http #World Wide Web HTTP > > http 80/udpwww www-http #World Wide Web HTTP > > > > Should be: > > http 80/tcpwww www-http #World Wide Web HTTP > > http 80/udp #[not used] > > > > Don't you think? At least that way you don't have to read all of the > > rfcs to construct a firewall ;). > > And the output of netstat (trafshow, etc.) would be considerably easier to > read. The -n option to trafshow disables number->name translation for both addresses and ports, although that might be more than what is wanted. I do know what you mean though. 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. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
readdirplus is very cool, any other nfs client suggestions?
Spent quite a bit of time today playing around with the newly
repaired readdirplus option for nfs clients in -current. My thanks to Matt
Dillon and Bill Paul. For those that don't remember, I'm trying to use
amd/nfs client stuff on some freebsd web servers that read their data from
our sun (and now sun + netapp) web farm. I have a script that used to lock
up amd and/or nfs and/or the whole machine pretty regularly. I've run it
about 100 times today in various conditions with no ill effects. About
this I am quite pleased. :)
Since I'm new to nfs, and wasn't aware of the readdirplus option,
it dawns on me that there might be other cool things I'm not using that
also might be a benefit. I'm using amd for now, although this might be
replaced with plain old hard mounts at some time in the near future. The
following options I've cobbled together from advice on the lists, my
reading of the man pages and other documentation, and a lot of
experimentation. Any comments or suggestions for improvements would be
welcome.
Thanks,
Doug
amd.conf:
[ global ]
map_type = file
search_path =/etc
auto_dir = /usr/amd/realmounts
normalize_hostnames = yes
plock = yes
selectors_on_default = yes
[ /usr/amd/Interfaces ]
map_name = amd.Interfaces
amd.Interfaces:
/defaults type:=nfs;opts:=rw,vers=3,readdirplus,intr,proto=udp
* rhost:=IP${key};rfs:=/Space/${key}
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: readdirplus is very cool, any other nfs client suggestions?
On Fri, 30 Jul 1999, Matthew Dillon wrote: > The only other major feature is the nq leasing stuff for cache coherency, > but it is highly experimental and you probably shouldn't use it. Plus > very few other OS's support it. heh... I'm just happy when the stuff works that's supposed to work. I really don't want to push my luck. > There is a lot of tweaking you can do with 'normal' nfs options, > such as tuning the read & write block size, adjusting cache timeouts > for various parameters, and so forth. > > man mount_nfs and look at the various -o options available. Yeah, I've been reading the various man pages and things for quite a while now and it's starting to synch in. Do you have any suggestions for additional reading? The O'Reilly book seems a bit out of date, but I'll try it if folks say it's good. Basically my problem is that there are so MANY options, and my knowledged about potential side effects is very limited. Thanks for your response, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to 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
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
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: 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" > 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: readdirplus is very cool, any other nfs client suggestions?
On 2 Aug 1999, Dag-Erling Smorgrav wrote: > Alfred Perlstein writes: > > DES: can you elaborate? you think it may cause problems with amd > > since it's like an NFS buffer isn't it and would work over the > > loopback... > > I used loopback mounts to test NFS make worlds a while ago Hrrmmm... I'm not sure where the concern about loopback stuff comes from. Does amd use the loopback interface to communicate with anything? Thanks, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
ignoretime in login.conf??
I'm doing some research on resource limits and I can't find any information at all on the ignoretime capability that's in /usr/src/etc/login.conf. A 'grep -iR ignoretime *' in /usr/src didn't return any hits outside of the login.conf files in /usr/src/etc and the picobsd stuff. Does anyone have any information on what this is or what it's used for? If not, perhaps it should be removed from the examples? Also, the 'boolean' option is essentially undocumented in the login.conf man page. It's mentioned once, but there is no example of how it works or the fact that the @ sign is the symbol for it. The info is in login_cap(3), but it's hard to decipher for a non-programmer. I'll put this on my list if no one else wants to take it, and submit a PR. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
login.conf restrictions for suid processes possible? (fwd)
No answer on -questions, and this is pretty urgent for me atm. Any help appreciated. Doug Greetings, :) I am working on some resource limit stuff and would like to be able to use login.conf to restrict the number of cgi processes that certain users can run. Unfortunately, the proprietary cgi product we use is owned by root and suid's to the user who owns the script that it is called to run. (This is not what I would call a "good idea," but it's what I have to work with.) I've created a login class with the appropriate permissions, and if I put a test user in that class and test its limits with normal system processes (like ls, sleep, etc.) it follows all the rules. However when I start miva (proprietary cgi) processes for scripts owned by that user, it ignores the limits, presumably because the process starts its life as root. S, the question is, how can I do what I want to do, and if I can't do it with login.conf does anyone have any other suggestions? Specifically I need to restrict the amount of ram and the number of processes on a per user basis. I'm working on a -current system, but I don't think this issue bears directly on -current. Thanks for any help, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-questions" 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: login.conf restrictions for suid processes possible? (fwd)
On Thu, 5 Aug 1999, Mike Smith wrote:
> > I am working on some resource limit stuff and would like to be
> > able to use login.conf to restrict the number of cgi processes that
> > certain users can run. Unfortunately, the proprietary cgi product we use
> > is owned by root and suid's to the user who owns the script that it is
> > called to run. (This is not what I would call a "good idea," but it's what
> > I have to work with.)
> >
> > I've created a login class with the appropriate permissions, and
> > if I put a test user in that class and test its limits with normal system
> > processes (like ls, sleep, etc.) it follows all the rules. However when I
> > start miva (proprietary cgi) processes for scripts owned by that user, it
> > ignores the limits, presumably because the process starts its life as
> > root.
> >
> > S, the question is, how can I do what I want to do, and if I
> > can't do it with login.conf does anyone have any other suggestions?
> > Specifically I need to restrict the amount of ram and the number of
> > processes on a per user basis. I'm working on a -current system, but I
> > don't think this issue bears directly on -current.
>
> You need to pester the vendor to correctly switch limits when they
> switch UIDs.
>
> Alternatively, if this is unlikely _and_ the application is dynamically
> linked, you could produce a library containing patched set*id functions
> and force it into the app using LD_PRELOAD.
Grrrfl. Ok, that's what I thought, but I do appreciate the
confirmation. We have a pretty good relationship with the vendor so I'll
take that route first.
Thanks,
Doug
--
On account of being a democracy and run by the people, we are the only
nation in the world that has to keep a government four years, no matter
what it does.
-- Will Rogers
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: login.conf restrictions for suid processes possible? (fwd)
On Thu, 5 Aug 1999, John Polstra wrote: > In article <199908051755.kaa13...@dingo.cdrom.com>, > Mike Smith wrote: > > > I am working on some resource limit stuff and would like to be > > > able to use login.conf to restrict the number of cgi processes that > > > certain users can run. Unfortunately, the proprietary cgi product we use > > > is owned by root and suid's to the user who owns the script that it is > > > called to run. (This is not what I would call a "good idea," but it's what > > > I have to work with.) > [...] > > You need to pester the vendor to correctly switch limits when they > > switch UIDs. > > > > Alternatively, if this is unlikely _and_ the application is dynamically > > linked, you could produce a library containing patched set*id functions > > and force it into the app using LD_PRELOAD. > > N.B., LD_PRELOAD won't work if the program is setuid or setgid. I'm > not 100% sure from the original post whether that's the case or not. Yes, the program is owned by root, has permissions -rwsr-xr-t and suid's to the user who owns the script it's called to run. I'm aware that the sticky bit is ignored on BSD for executables, but that's how it comes from the vendor so my boss doesn't want to mess with it. Thanks, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP stack hackers take a bow
On Thu, 5 Aug 1999, Bill Fumerola wrote: > On Thu, 5 Aug 1999, Andrew Gallatin wrote: > > > It was very annoying that the person who wrote the local News & > > Observer article seemed disappointed that we were not running linux & > > probably because of that, didn't mention the OS at all in her article. > > It's sad it has to be that way. I can't think of another product that > is treated so poorly in the wake of another's success. Hmmm... OS/2 maybe? :) (Which is not to say that IBM didn't work very hard at shooting themselves in their collective feet at every opportunity.) But seriously folks, this kind of thing happens all the time in the computer business. The best way to handle it is to keep smiling and talk to the ones who will listen, and report accurately. The word is getting out slowly. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: Please support FreeBSD 3.x as host OS]
On Fri, 6 Aug 1999 john_wilson...@excite.com wrote: > This is kinda different from what the original poster received. > Keep badgering! But ONLY if you ARE willing to pay for it if they make one. We don't need a repeat of the CDE debacle. Doug > > Hi John, > > > > Thank you for the interest in our software. > > > > We've received a number of requests to make a 'VMware for FreeBSD' > > product. We are looking into doing such a project but have no plans to > > develop this product at this time. > > > > Mehrdad Amir, > > VMware, Inc. > > > > > > Get FREE voicemail, fax and email at http://voicemail.excite.com > Talk online at http://voicechat.excite.com > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: Please support FreeBSD 3.x as host OS]
On Fri, 6 Aug 1999, Donald Burr wrote: > I don't know about you, but I for one am ready and willing to plunk down > my hard-earned $$$ for VMware if it came to FreeBSD. Sorry I wasn't more clear. I am too, and I'd *really* like to see it happen. There is stuff both at work and at home that has to be run in windows (as much as I'm not happy about that fact, that's just life) and wine just doesn't cut it. When I get some free time (yeah, right) I'm going to try bochs again now that they have networking ability, but at this point my time is more valuable to me than the price of vmware, and it'd be great to get them into our market since they're developing a pretty good profile for themselves. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
perl can't manify during make upgrade
Doing a make upgrade tonight I see the following errors (bunches of them). Manifying B::Showlex.3 ELF interpreter /usr/libexec/ld-elf.so.1 not found Abort trap Manifying B::Stackobj.3 ELF interpreter /usr/libexec/ld-elf.so.1 not found Abort trap Manifying B::Terse.3 ELF interpreter /usr/libexec/ld-elf.so.1 not found Abort trap Manifying B::Xref.3 ELF interpreter /usr/libexec/ld-elf.so.1 not found Abort trap Manifying B.3 ELF interpreter /usr/libexec/ld-elf.so.1 not found Abort trap Manifying O.3 ELF interpreter /usr/libexec/ld-elf.so.1 not found Abort trap Manifying DB_File.3 ELF interpreter /usr/libexec/ld-elf.so.1 not found Abort trap Manifying Data::Dumper.3 ELF interpreter /usr/libexec/ld-elf.so.1 not found I suspect that this is due to the fact that the elf libraries have been built but not installed at this point in the program, but I thought y'all might like to know. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Please review: New 'make upgrade' web page
Making good on a promise I made quite a while back I've put up a web page with hopefully comprehensive instructions on going from 2.2.8 to 3.x via 'make upgrade.' This page is aimed at a less experienced user and gives a step by step list of procedures to follow to help ensure maximum possibilities of success and convenience. I would appreciate it very much if some of y'all that are familiar with this procedure would take a few minutes and read through the page with an eye toward offering constructive criticism. I have now done two 'make upgrade's following these instructions and both have been successful. I cobbled together the information from various posts to the lists over the last year and my experience doing the two upgrades. Some of the recommendations may seem overly paranoid, but please keep the target audience in mind. TIA, Doug http://home.san.rr.com/freebsd/make-upgrade.html To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Fix/tuning to improve slow NFS writes?
Well my NFS reliability at work has gone way up, to the point where we are now having time to look at the finer things in life, like performance tuning. Performance on reads has been quite good, but when the cgi scripts that the users are running on these machines have large writes to do (like re-indexing a database) the writes go really slow. So slow in fact that they sometimes time out, the CGI engine dies, and the job is never completed, causing it to be restarted by the user. So, the big question is whether there is anything we can tune to speed up the writes. The freebsd machines are NFS clients to the sun servers doing most of the web processing. Overall performance on the reads seems to be best with nfs v3 over udp, which is what I'm using now. All of the web server directories are soft mounted directly, with no amd currently in use. thanks, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Fix/tuning to improve slow NFS writes?
Matthew Dillon wrote: > > : So, the big question is whether there is anything we can tune to > speed up > :the writes. The freebsd machines are NFS clients to the sun servers doing > :most of the web processing. Overall performance on the reads seems to be > :best with nfs v3 over udp, which is what I'm using now. All of the web > :server directories are soft mounted directly, with no amd currently in use. > : > :thanks, > : > :Doug > > Well, NFS buffers are usually sent over the network the moment they > are full. If you are not running any nfsiod's I should have mentioned, I have 20 nfsiod's running. I started so many initially to help in the stress testing I was doing, but I left them running because the servers are handling from 2-4 requests per second and we have lots of ram in the boxes. Is there a way to figure out how many are getting used concurrently, or is too many not a problem? Thanks, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Fix/tuning to improve slow NFS writes?
Alfred Perlstein wrote: > > On Mon, 9 Aug 1999, Doug wrote: > > > Matthew Dillon wrote: > > > > > > : So, the big question is whether there is anything we can tune to > > > speed up > > > :the writes. The freebsd machines are NFS clients to the sun servers doing > > > :most of the web processing. Overall performance on the reads seems to be > > > :best with nfs v3 over udp, which is what I'm using now. All of the web > > > :server directories are soft mounted directly, with no amd currently in > > > use. > > > : > > > :thanks, > > > : > > > :Doug > > > > > > Well, NFS buffers are usually sent over the network the moment they > > > are full. If you are not running any nfsiod's > > > > I should have mentioned, I have 20 nfsiod's running. I started so many > > initially to help in the stress testing I was doing, but I left them > > running because the servers are handling from 2-4 requests per second and > > we have lots of ram in the boxes. Is there a way to figure out how many are > > getting used concurrently, or is too many not a problem? > > ? > > You need to run 'nfsd' on the servers, not nfsiod. Sorry I wasn't clear. That's what I get for writing posts like this when I'm tired. In that paragraph "servers" refers to the freebsd cgi/web servers that are acting as NFS clients to the sun boxes. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ignoretime in login.conf??
Dag-Erling Smorgrav wrote: > > Doug writes: > > Also, the 'boolean' option is essentially undocumented in the > > login.conf man page. It's mentioned once, but there is no example of how > > it works or the fact that the @ sign is the symbol for it. The info is in > > login_cap(3), but it's hard to decipher for a non-programmer. I'll put > > this on my list if no one else wants to take it, and submit a PR. > > login.conf is a capability database like any other and therefore > follows the syntax described in the getcap(3) man page. Yes, which is basically restating my point, namely that if you don't already understand how it works the man page is of no use to you. :) I will produce diffs sometime soon. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re:(2) hey
On Fri, 13 Aug 1999, Evren Yurtesen wrote: > Well, I am the person who has this problem. > The RFCs does not explicitly say that we should not use underscore > character > as far as I understood. This is a common misunderstanding. The only valid characters in hostnames to be used on the global internet are letters, numbers and the dash character, "-". Underscores are not valid, at all, period. I realize that the RFC's don't seem to be clear on this point, however you can rest assured that such is the case. Good luck, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: (2) hey
On Thu, 12 Aug 1999, Louis A. Mamakos wrote: > But the DNS is used to hold all sorts of information. For example, how do > you reconcile domain names like: > > 42.10.202.144.IN-ADDR.ARPA > > in the DNS? It violates the "starts with alpha" "requirement" in 952 and 1101 E.. even if that argument weren't silly on its face, the 'starts/ends with alpha' requirement has been relaxed for some time now. First for legacy domains like 3com.com, and next for newer ones like 411.com. The only rule that is currently being enforced is that no label can begin or end with a dash. > that you quotes, yet we use these things all the time. In fact, you can > send email to that domain name because it has an A record associated with > it, as well as a PTR record. That IS a violation of the standard, since A records are not valid for hosts in in-addr.arpa. > What do I know; I was just the first chair of the domain name working group > in the IETF so many years ago before it got fashionable. Well, things change. :) Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: (2) hey
On Thu, 12 Aug 1999, Louis A. Mamakos wrote: > > > > That IS a violation of the standard, since A records > > are not valid for hosts in in-addr.arpa. > > > > And next I suppose you'll tell me that PTR records are not valid > outsize of the IN-ADDR.ARPA portion of the DNS namespace? Given how PTR RR's are defined, I'd have to say, ayyup. > What people really miss is that the DNS is a distributed database > with delegation, used for all sorts of purposes. You get no argument from me there. However there is a difference between defining "louie's_map_zone." and using that for whatever you want to use it for, and trying to hammer your stuff into areas that already have definitions. The tools exist to extend the protocol into other areas as you see fit, and I say more power to you. But please don't try and drum up sympathy for that "DNS should be all things to all people" line, it didn't work well back then and doesn't work at all now. It's all we can do nowadays to get people to configure "normal" things properly. AFAIC, the software could stand to be smarter than it is already because they keep making better idiots. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: (2) hey
Tony Finch wrote: > > Doug wrote: > >Louis A. Mamakos wrote: > >>[lost attribution] > >>> > >>> That IS a violation of the standard, since A records are not valid > >>> for hosts in in-addr.arpa. > >> > >> And next I suppose you'll tell me that PTR records are not valid > >> outsize of the IN-ADDR.ARPA portion of the DNS namespace? > > > > Given how PTR RR's are defined, I'd have to say, ayyup. > > I suggest you read RFC 2317 I'd suggest you read what I actually wrote. :) Nothing in either RFC that you quoted, or any of your examples contradicted my actual point, which was that PTR records are not valid outside of in-addr.arpa name space. If you believe they are, give valid working examples and explain their meaning, since there currently is not a definition for their use outside of in-addr.arpa. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port & BSD VFS Rewrite
"Brian F. Feldman" wrote: > > On Sat, 14 Aug 1999, James Howard wrote: > > > On Fri, 13 Aug 1999, Mike Smith wrote: > > > > > It doesn't work like that; once it's been distributed with Linux it's > > > no longer BSD-licensed, it's GPLed. They would still be unable to > > > recover post-viral changes and reuse them in their own XFS product. > > > > I heard somewhere that Linux was released under a slightly modified GPL to > > permit the inclusion of BSD code. I assumed they did this to steal the IP > > stack. > > Most likely. s/steal/use/. We can't champion the BSD (read, "Use this code for whatever you want") license then cast aspersions at people who use it for things we don't like. Let's at least be logically consistent. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
Terry Lambert wrote: > I object because it perpetuates a situation which has made it > take this long to get the issue addressed. > > I also object because BIND 9 is currently in the works, and there > is talk of replacing the records with A6 records in the DNSEXT > working group. > > The resolver should be in a seperate library to facilitate speedy > integration of future releases, and because its designers put it > in a seperate library. > > The correct way to get historical BSD behaviour, i.e. linking libc > gives you the resolver, is to take advantage of ELF, and link the > libc against the libresolver, and thus incorporate it by reference > (if this doesn't work in FreeBSD, it should; I haven't checked). > > Of course, my ideal world would update all of the Makefiles for > all of the network utilities (including the ports) to know about > libresolver explicitly, but that's unlikely to come to pass. Here here. Think of this as a "me too," or a vote in favor of each of the points above. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
Wilfredo Sanchez wrote: > > A group of us at Apple are trying to figure out how to handle > situations where a filesystem with "foreign" user ID's are present. > The basic problem is that the user experience using Unix semantics > are not really pleasant. I think some examples would help: > > I'm working with Joe on a project, and I have some sources I want > him to take a look at, so I mount a floppy disk. Well, that's a bad > example, because floppies are "out"... So I mount a zip disk with UFS > on it, and I copy my source tree onto it, and hand this to Joe. Joe > takes the disk home, and sticks it in his computer, and he finds > that he can't read the files, because I have a lamer umask, and as a > bonus, I don't have an account on his machine, so the files are owned > by some random UID. Having run into this problem myself, both with tar'ed archives and zip disks I came up with the following dream world one day. In my world there are two magic uid's, one for a "read only" user and one for a "read write" user. If I give Joe a zip disk with my files on it all owned by my uid, by default when he puts it in his drive at his workstation it comes up with all files owned by the read only user. He can read the files, copy them to his work station, etc. but he can't make changes to the existing files. If I want to let Joe change the files on my disk I can set the rw flag, so when he pops it in his drive it comes up owned by the "read write" user. (Still assuming that Joe and I have mismatched uid's.) In a system like this I'd also like to see a flag that lets the owner require that the uid semantics are enforced. Also, the flags should be settable on the file, directory and disk levels. Finally in an ultra-paranoid environment you could set an option that requires that the uid matchup is for the actual person, similar to the way an ssh public key/private key pair works. Hope this is useful, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Interesting ssh + X + tcp_wrappers problem
I've been doing some housecleaning lately and I finally decided to set up a one-way ssh authentication from my workstation to my gateway machine. I set up the ssh keys and that was all good. Then I went to start an X app on the gateway expecting it to just pop up on the workstation's X display (happens to be cvsup, but I don't think that's relevant) and I got the following: error: Fwd X11 connection from dt010nb9.san.rr.com refused by tcp_wrappers. I am using natd on the gateway to hook me up to my cable modem. The hostname is the one that the world sees me as, and is assigned to the outside interface. I have the inside interface set up as 10.0.0.1, and the workstation is 10.0.0.2. I have ALL : 10.0.0.2 : allow in /etc/hosts.allow (and appropriate ipfw filtering set up of course), but I didn't have the address of the outside interface in there anywhere since I never expected it would be a problem for the machine to connect to itself. :) Now I am not sure if this is an sshd problem, an X problem, a tcp_wrappers problem, or what have you. I do know that once I put an entry for the outside interface address in hosts.allow it worked. The only problem I have with that is that with dhcp that address changes every time someone gets a wild hair and reboots the dhcp server, and they do that a couple times a month. This makes one more thing that I have to add to my "bugger-I-got-another-new-IP" script that I'd prefer to avoid. Thoughts, comments, suggestions welcome, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
Wilfredo Sanchez wrote: > > A group of us at Apple are trying to figure out how to handle > situations where a filesystem with "foreign" user ID's are present. > The basic problem is that the user experience using Unix semantics > are not really pleasant. I think some examples would help: > > I'm working with Joe on a project, and I have some sources I want > him to take a look at, so I mount a floppy disk. Well, that's a bad > example, because floppies are "out"... So I mount a zip disk with UFS > on it, and I copy my source tree onto it, and hand this to Joe. Joe > takes the disk home, and sticks it in his computer, and he finds > that he can't read the files, because I have a lamer umask, and as a > bonus, I don't have an account on his machine, so the files are owned > by some random UID. Having run into this problem myself, both with tar'ed archives and zip disks I came up with the following dream world one day. In my world there are two magic uid's, one for a "read only" user and one for a "read write" user. If I give Joe a zip disk with my files on it all owned by my uid, by default when he puts it in his drive at his workstation it comes up with all files owned by the read only user. He can read the files, copy them to his work station, etc. but he can't make changes to the existing files. If I want to let Joe change the files on my disk I can set the rw flag, so when he pops it in his drive it comes up owned by the "read write" user. (Still assuming that Joe and I have mismatched uid's.) In a system like this I'd also like to see a flag that lets the owner require that the uid semantics are enforced. Also, the flags should be settable on the file, directory and disk levels. Finally in an ultra-paranoid environment you could set an option that requires that the uid matchup is for the actual person, similar to the way an ssh public key/private key pair works. Hope this is useful, Doug 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: (forw) Re: ndc(8)
On Fri, 27 Aug 1999, Anders Andersson wrote: > - Forwarded message from Nik Clayton - > > Date: Thu, 26 Aug 1999 21:20:16 +0100 > From: Nik Clayton > To: Anders Andersson > Cc: freebsd-...@freebsd.org > Subject: Re: ndc(8) > Message-ID: <19990826212016.d86...@catkin.nothing-going-on.org> > X-Mailer: Mutt 0.95.4i > Organization: FreeBSD Project http://www.freebsd.org/> > > On Thu, Aug 26, 1999 at 10:02:01AM +0200, Anders Andersson wrote: > > I found that ndc(8) man page is a little wrong, for example > > > > 'stats Causes named to dump its statistics to /var/tmp/named.stats' > > > > is not correct, since named.stats get dumped to /etc/namedb/named.stats. > > > > It should read: > > > > 'stats Causes named to dump its statistics to /etc/namedb/named.stats' > > > > This also applies for /var/tmp/named_dump.db, that one goes also in > > /etc/namedb. > > Guys, before we fix the manpage on this, could someone please follow > this up with -hackers? I was under the impression (but could be wrong) > that programs weren't meant to do this sort of thing in /etc (or > subdirectories of /etc) and that /var/ is the best place for them. > > As I say, I could be wrong, but it'd be nice to get confirmation from > -hackers that this is the expected behaviour. You are correct, a read-only /etc/ is always part of the plan, and /var is the proper place for this kind of info to be dumped. Also, before we invest a lot of time in this, people should be aware that ndc is fundamentally different in BIND 8.2.x. This is not to say that fixing this now is not a good thing, just that it's not worth a whole LOT of time since things will be changing whenever the new BIND is imported. HTH, Doug -- "My mama told me, my mama said, 'don't cry.' 'She said you're too young a man to have as many women you got.' I looked at my mother dear and didn't even crack a smile. I said, 'If women kill me, I don't mind dyin!'" - John Belushi as "Joliet" Jake Blues, "I Don't Know" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: How bullet-proof should the /etc/rc* scripts be?
"Stephen J. Roznowski" wrote: > > I'm trying to build a stripped down version of FreeBSD and have run > across a few oddities in the startup scripts. Ok, first thing is, if you are going to hack up some custom stuff you're pretty much in the driver's seat on issues like this. That's not to say that the rc*, etc. scripts couldn't use some work, in fact some of us are doing just that. > 1. Should commands be wrapped in a check for their existance? For >example: swapon, adjkerntz, etc. If failed execution of the command will leave the system in an unusable state, yes. (Assuming by "check for their existance" you mean using the -x flag to 'test'.) If the system can continue booting even if the command fails, but the user needs to know the command failed, you should test the exit code and act appropriately. If no one cares about the command you don't need to do this, but then why run it at all? > 2. Should everything be wrapped in a "rc.conf" variable? For example, >the section with "mount -a -t nfs" (even though it silently exists >if no NFS filesystems exist). No. That specific case refers to entries in /etc/fstab (the -a is your clue), so regardless of the presence or abscence of nfs stuff in rc.conf that command should be run. There are other commands like this, especially in rc.network that fall into the "we can just run this and nothing bad will happen if we don't need it" category. In a situation like yours that's bad, and in general I'm for making *less* assumptions about the state of the system, but you have to start _somewhere_. > 3. How much checking should be done before executing commands? As it >stands now, if you don't have any ptys, the chflags/chmod/chown >will fail -- should this be wrapped with an if statement? This is a little tougher. I would say that having NO pty's at all is a rather extreme case, but while I'm doing the review I'll give this another look. Can you send me the filename and line number of this specific case in a private e-mail please? That way I won't miss it. > 4. What is the point of the "stty status '^T' at the top of the rc file? Frankly, that one stumps me too. :) There are still plenty of "We've always done it that way" items in the various rc files, that may be one of them. In answer to the question in your subject line, I would say "More so than they are now." Comments and suggestions are welcome, preferably accompanied by unified diffs. :) Good luck with your project, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Please review: rc file changes
Greetings,
As previously discussed, here is a first draft of the rc* script mods. I
consider the first step in this process to be Jordan's cleanup of the
variable syntax. This is step 2, which most notably converts test's dealing
with variables to case wherever possible. It also does the following.
1. -f -> -r wherever it makes sense
2. value ) instead of value) for case statements
3. All cases of [, test, ; then, etc. converted to:
if [ blah ]; then
4. Made
# Comment
#
commands more consistent
5. Stripped whitespace off the end of a few lines
The attached diff is to rc, and was generated with -ubB to ease
understanding of the substantive changes. You can view the actual file at
http://gorean.org/rc. I would appreciate y'all reviewing these changes for
style, substance, or anything else relevant to the matter at hand. My hope
is that any modifications can be discussed prior to my doing the rest of
the work, which I plan to tackle this weekend. There are also a few
questions sprinkled into the file, comments or suggestions on those are
welcome.
This version of the file is tested lightly, which is to say that I
booted
with it after my upgrade to the most recent sources on -current tonight.
Obviously more rigorous testing will be necessary before this gets
committed, although the changes are extremely straightforward.
Questions:
1. Under what circumstances would $early_nfs_mounts be set? The only
mention of this variable that I could find is in /etc/rc, and I can't see
where it would be set.
2. Do we want to move to 'logger' instead of echo for the various little
statements in the rc* files during boot? I for one would highly recommend
this change, since it makes remote administration TONS easier. However the
last time it came up I seem to remember it being one of those "religious"
issues...
3. Anything else I should be looking at in this phase of the game?
Thanks,
Doug--- /etc/rc Thu Aug 26 21:02:19 1999
+++ rc Thu Aug 26 22:57:06 1999
@@ -8,24 +8,25 @@
# and the console is the controlling terminal.
# Note that almost all the user-configurable behavior is no longer in
-# this file, but rather in /etc/defaults/rc.conf. Please check this file
+# this file, but rather in /etc/defaults/rc.conf. Please check that file
# first before contemplating any changes here.
stty status '^T'
# Set shell to ignore SIGINT (2), but not children;
# shell catches SIGQUIT (3) and returns to single user after fsck.
+#
trap : 2
trap : 3 # shouldn't be needed
-HOME=/; export HOME
+HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin
-export PATH
+export HOME PATH
# BOOTP diskless boot. We have to run the rc file early in order to
# retarget various config files.
#
-if [ -f /etc/rc.diskless1 ]; then
+if [ -r /etc/rc.diskless1 ]; then
dlv=`/sbin/sysctl -n vfs.nfs.diskless_valid 2> /dev/null`
if [ ${dlv:=0} != 0 ]; then
. /etc/rc.diskless1
@@ -34,59 +35,68 @@
# If there is a global system configuration file, suck it in.
#
-if [ -f /etc/defaults/rc.conf ]; then
+if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
-elif [ -f /etc/rc.conf ]; then
+elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf
fi
# Configure ccd devices.
-if [ -f /etc/ccd.conf ]; then
+#
+if [ -r /etc/ccd.conf ]; then
ccdconfig -C
fi
-if [ "${start_vinum}" = "YES" ]; then
+case ${start_vinum} in
+ [Yy][Ee][Ss] )
vinum start
-elif [ -n "${vinum_drives}" ]; then
+ ;;
+ * )
+ if [ -n "${vinum_drives}" ]; then
vinum read ${vinum_drives}
-fi
+ fi
+ ;;
+esac
swapon -a
-if [ "$1" = "autoboot" ]; then
+case $1 in
+ autoboot )
echo Automatic reboot in progress...
fsck -p
case $? in
- 0)
+ 0 )
;;
- 2)
+ 2 )
exit 1
;;
- 4)
+ 4 )
reboot
echo "reboot failed... help!"
exit 1
;;
- 8)
+ 8 )
echo "Automatic file system check failed... help!"
exit 1
;;
- 12)
+ 12 )
echo "Reboot interrupted"
exit 1
;;
- 130)
+ 130 )
# interrupt before catcher installed
exit 1
;;
- *)
+ * )
echo "Unknown error in reboot"
exit 1
;;
esac
-else
+ ;;
+ * )
echo Skipping disk checks ...
-fi
+ ;;
+esac
set -T
trap "echo 'Reboot interrupted'; exit 1" 3
@@ -94,33 +104,4
Splash screen problem after being interrupted
Tonight while testing my rc file changes I decided to interrupt the splash screen display I have to see the boot messages. I hit scroll lock to do this, and it killed the splash screen, but when I went to log in the keyboard on the console was pretty much fubar. Every key was mapped to a different value, and I couldn't even C-A-D to reboot clean, I had to do a soft reset. Obviously this is a "... well don't do that" case, but I'm not sure it should be fatal. Hopefully this is of use to someone. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
Chris Costello wrote: > > On Thu, Aug 26, 1999, Doug wrote: > > Greetings, > > > > As previously discussed, here is a first draft of the rc* script > > mods. I > > consider the first step in this process to be Jordan's cleanup of the > > variable syntax. This is step 2, which most notably converts test's dealing > > with variables to case wherever possible. It also does the following. > > > 2. value ) instead of value) for case statements > >Why? What's wrong with `value)'? Nothing functionally, but I find case statements much easier to read with the extra whitespace. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
On Fri, 27 Aug 1999, Chris Costello wrote: > On Thu, Aug 26, 1999, Doug wrote: > > > > 2. value ) instead of value) for case statements > > > > > >Why? What's wrong with `value)'? > > > > Nothing functionally, but I find case statements much easier to read with > > the extra whitespace. > >Would that not cause problems? Nope. As most things shell it (rightly) ignores the whitespace. Take a look at this little script to prove it to yourself: #!/bin/sh VAR=foo case $VAR in foo ) echo "I don't care about whitespace" ;; foo) echo "OOoops, guess I do" ;; esac VAR='foo ' case $VAR in foo ) echo "D'oh! I see the whitespace in the variable" ;; foo) echo "D'oh! I don't see the whitespace in the variable" ;; 'foo ' ) echo "I see what I am supposed to see" ;; esac Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
Oliver Fromme wrote: > > Doug wrote in list.freebsd-hackers: > > [...] > > 2. value ) instead of value) for case statements > > [...] > > case $? in > > -0) > > +0 ) > > ;; > > -2) > > +2 ) > > exit 1 > > ;; > > -4) > > +4 ) > > reboot > > echo "reboot failed... help!" > > exit 1 > > ;; > > [...] > > Why?!? I like the existing "case" style _much_ better, > it's more readable and emphasizes the structure. Ok, universal acclaim in both public and private mail is for: case $foo in optinon ) as opposed to: case $foo in option ) so I'll modify that one. It actually improves readability in some cases, although the latter is a matter of personal style. I would really prefer to stick with option ) vs. option) though, but if it becomes a show-stopper I can compromise on that one too. All I ask is that people give it a chance first. :) Keep those cards and letters coming, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
Doug wrote:
>
> Greetings,
>
> As previously discussed, here is a first draft of the rc* script
> mods. I
> consider the first step in this process to be Jordan's cleanup of the
> variable syntax. This is step 2, which most notably converts test's dealing
> with variables to case wherever possible. It also does the following.
>
> 1. -f -> -r wherever it makes sense
> 2. value ) instead of value) for case statements
> 3. All cases of [, test, ; then, etc. converted to:
>
> if [ blah ]; then
>
> 4. Made
> # Comment
> #
> commands more consistent
>
> 5. Stripped whitespace off the end of a few lines
>
> The attached diff is to rc, and was generated with -ubB to ease
> understanding of the substantive changes. You can view the actual file at
> http://gorean.org/rc. I would appreciate y'all reviewing these changes for
> style, substance, or anything else relevant to the matter at hand. My hope
> is that any modifications can be discussed prior to my doing the rest of
> the work, which I plan to tackle this weekend. There are also a few
> questions sprinkled into the file, comments or suggestions on those are
> welcome.
>
> This version of the file is tested lightly, which is to say that I
> booted with it after my upgrade to the most recent sources on -current
> tonight.
> Obviously more rigorous testing will be necessary before this gets
> committed, although the changes are extremely straightforward.
>
> Questions:
>
> 1. Under what circumstances would $early_nfs_mounts be set? The only
> mention of this variable that I could find is in /etc/rc, and I can't see
> where it would be set.
>
> 2. Do we want to move to 'logger' instead of echo for the various little
> statements in the rc* files during boot? I for one would highly recommend
> this change, since it makes remote administration TONS easier. However the
> last time it came up I seem to remember it being one of those "religious"
> issues...
>
> 3. Anything else I should be looking at in this phase of the game?
Ok, revised diff attached. I made the case indentation change and some
of
sheldon's suggestions are incorporated. I also neglected to mention
previously that I tuned up a few of the comments in the file, as well as
error output. I also was more rigorous about making whitespace consisten on
this pass. Removing double spaces, converting spaces to tabs, etc. This is
much more like what I want the final version to look like. All of the above
still applies, except that due to the more "normal" indentation a straight
diff -u is more readable.
Assuming this works for everyone, I will proceed with the other rc*,
etc.
scripts, except rc.network which sheldon informed me he is currently
working on.
Doug--- /usr/src/etc/rc Thu Aug 26 20:56:36 1999
+++ rc Fri Aug 27 09:52:39 1999
@@ -8,24 +8,25 @@
# and the console is the controlling terminal.
# Note that almost all the user-configurable behavior is no longer in
-# this file, but rather in /etc/defaults/rc.conf. Please check this file
+# this file, but rather in /etc/defaults/rc.conf. Please check that file
# first before contemplating any changes here.
stty status '^T'
# Set shell to ignore SIGINT (2), but not children;
# shell catches SIGQUIT (3) and returns to single user after fsck.
+#
trap : 2
trap : 3 # shouldn't be needed
-HOME=/; export HOME
+HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin
-export PATH
+export HOME PATH
-# BOOTP diskless boot. We have to run the rc file early in order to
+# BOOTP diskless boot. We have to run the rc file early in order to
# retarget various config files.
#
-if [ -f /etc/rc.diskless1 ]; then
+if [ -r /etc/rc.diskless1 ]; then
dlv=`/sbin/sysctl -n vfs.nfs.diskless_valid 2> /dev/null`
if [ ${dlv:=0} != 0 ]; then
. /etc/rc.diskless1
@@ -34,59 +35,68 @@
# If there is a global system configuration file, suck it in.
#
-if [ -f /etc/defaults/rc.conf ]; then
+if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
-elif [ -f /etc/rc.conf ]; then
+elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf
fi
# Configure ccd devices.
-if [ -f /etc/ccd.conf ]; then
+#
+if [ -r /etc/ccd.conf ]; then
ccdconfig -C
fi
-if [ "${start_vinum}" = "YES" ]; then
+case ${start_vinum} in
+[Yy][Ee][Ss] )
vinum start
-elif [ -n "${vinum_drives}" ]; then
- vinum read ${vinum_drives}
-fi
+ ;;
+* )
+ if [ -n "${vinum_drives}" ]; then
+ vinum read ${vinum_drives}
+ fi
+ ;;
+esac
swapon -a
-if [ "$1" = "autoboot" ]; then
+case $1 in
+autoboot )
echo Automatic reboot in progress...
Re: Please review: rc file changes
On Fri, 27 Aug 1999, Nate Williams wrote: > [ I'm nit-picking here, feel free to ignore ] A) You're in really good company. :) B) I expected a lot of nits to be picked on this project, which is why I wanted to do a "first draft" and solicit comments. I'm not overly concerned about getting _my_ way on a lot of these things, so long as we get a style that is consistent and that everyone can live with. > > Doug--- /usr/src/etc/rc Thu Aug 26 20:56:36 1999 > > +++ rc Fri Aug 27 09:52:39 1999 > > @@ -8,24 +8,25 @@ > > # and the console is the controlling terminal. > > > > # Note that almost all the user-configurable behavior is no longer in > > -# this file, but rather in /etc/defaults/rc.conf. Please check this file > > +# this file, but rather in /etc/defaults/rc.conf. Please check that file > > # first before contemplating any changes here. > > > > Sentences are supposed to have two spaces before you start the next > sentence. Well, that was definitely the old typographical convention, but in the digital age it's fallen into disfavor. It was easier to delete the second space to make them all consistent, but I can go with double spaces if that's the consensus. > Thanks for doing this! My pleasure actually. This project is something that I've wanted to see accomplished for several years. I'm happy that the momentum is swiging this way finally. Doug -- "My mama told me, my mama said, 'don't cry.' She said, 'you're too young a man to have as many women you got.' I looked at my mother dear and didn't even crack a smile. I said, 'If women kill me, I don't mind dyin!'" - John Belushi as "Joliet" Jake Blues, "I Don't Know" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
Nik Clayton wrote: > > On Fri, Aug 27, 1999 at 11:23:06AM -0700, Doug wrote: > > On Fri, 27 Aug 1999, Nate Williams wrote: > > > Sentences are supposed to have two spaces before you start the next > > > sentence. > > > > Well, that was definitely the old typographical convention, but in > > the digital age it's fallen into disfavor. It was easier to delete the > > second space to make them all consistent, but I can go with double spaces > > if that's the consensus. > > I did this change over on the FDP in the Handbook, thinking it didn't make > any difference either. > > Then I got deluged with e-mail from people telling me that lots of editors > use the double space as part of their heuristic to determine where sentences > start and end. > > And I turned it back :-) Okey dokey, I can take a hint. :) Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
Matthew Dillon wrote: > I guess they don't teach manual typewriting classes any more :-) Actually I took that class in Jr. High School, way back in '77. It was the only good advice my Jr. High guidance counselor gave me. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
Cleaned up this post a little for the final (?) version of rc.diff. Back
by popular demand, double spaces after the periods! Well, partly by popular
demand and partly because I think it bouys my argument for a space after
the case options. :) Note the changed URL for the real file. Without
further comment this is the final verion of the rc file diff, but I will
submit it along with the rest when I'm done.
Greetings,
As previously discussed, here is a first draft of the rc* script
mods. I
consider the first step in this process to be Jordan's cleanup of the
variable syntax. This is step 2, which most notably converts test's dealing
with variables to case wherever possible. It also does the following.
1. -f -> -r wherever it makes sense
2. value ) instead of value) for case statements
3. All cases of [, test, ; then, etc. converted to:
if [ blah ]; then
4. Made
# Comment
#
commands
more consistent
5. Stripped whitespace off the end of a few lines
6. Tuned up a few of the comments in the file, as well as error output. I
also was more rigorous about making whitespace consisten on this pass.
Removing double spaces, converting spaces to tabs, etc.
The attached diff is to rc, and was generated with -u. You can view
the actual file at http://gorean.org/rcfiles/rc. I would appreciate y'all
reviewing these changes for style, substance, or anything else relevant to
the matter at hand. My hope is that any modifications can be discussed
prior to my doing the rest of the work, which I plan to tackle this
weekend. There are
also a few questions sprinkled into the file, comments or suggestions on
those
are welcome.
This version of the file is tested lightly, which is to say that I
booted with it after my upgrade to the most recent sources on -current
tonight.
Obviously more rigorous testing will be necessary before this gets
committed, although the changes are extremely straightforward.
Questions:
1. Under what circumstances would $early_nfs_mounts be set? The only
mention of this variable that I could find is in /etc/rc, and I can't see
where it would be set.
2. Does the following constitute a security hole?
# Make a bounds file for msgs(1) if there isn't one already
# "Delete important files with symlink" security hole?
#
if [ ! -f /var/msgs/bounds ]; then
echo 0 > /var/msgs/bounds
fi
3. Do we want to move to 'logger' instead of echo for the various little
statements in the rc* files during boot? I for one would highly recommend
this change, since it makes remote administration TONS easier. However the
last time it came up I seem to remember it being one of those "religious"
issues... I see this as step 3. of the project, and will go ahead with it
after step 2. is done if there is no objection.
3. Anything else I should be looking at in this phase of the game?
Doug--- /usr/src/etc/rc Sat Aug 28 13:51:10 1999
+++ rc Sat Aug 28 14:08:25 1999
@@ -8,24 +8,25 @@
# and the console is the controlling terminal.
# Note that almost all the user-configurable behavior is no longer in
-# this file, but rather in /etc/defaults/rc.conf. Please check this file
+# this file, but rather in /etc/defaults/rc.conf. Please check that file
# first before contemplating any changes here.
stty status '^T'
# Set shell to ignore SIGINT (2), but not children;
# shell catches SIGQUIT (3) and returns to single user after fsck.
+#
trap : 2
trap : 3 # shouldn't be needed
-HOME=/; export HOME
+HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin
-export PATH
+export HOME PATH
# BOOTP diskless boot. We have to run the rc file early in order to
# retarget various config files.
#
-if [ -f /etc/rc.diskless1 ]; then
+if [ -r /etc/rc.diskless1 ]; then
dlv=`/sbin/sysctl -n vfs.nfs.diskless_valid 2> /dev/null`
if [ ${dlv:=0} != 0 ]; then
. /etc/rc.diskless1
@@ -34,59 +35,68 @@
# If there is a global system configuration file, suck it in.
#
-if [ -f /etc/defaults/rc.conf ]; then
+if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
-elif [ -f /etc/rc.conf ]; then
+elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf
fi
# Configure ccd devices.
-if [ -f /etc/ccd.conf ]; then
+#
+if [ -r /etc/ccd.conf ]; then
ccdconfig -C
fi
-if [ "${start_vinum}" = "YES" ]; then
+case ${start_vinum} in
+[Yy][Ee][Ss] )
vinum start
-elif [ -n "${vinum_drives}" ]; then
- vinum read ${vinum_drives}
-fi
+ ;;
+* )
+ if [ -n "${vinum_drives}" ]; then
+ vinum read ${vinum_drives}
+ fi
+ ;;
+esac
swapon -a
-if [ "$1" = "autoboot" ]; then
+case $1 in
+autoboot )
echo Automatic reboot in progress...
fsck -p
case $? in
- 0)
+ 0 )
;;
- 2)
+ 2 )
Re: Please review: rc file changes
Ben Smithurst wrote: > > Doug wrote: > > > Okey dokey, I can take a hint. :) > > Can you take another one, regarding the unnecessary spaces after the > values in your "case"s? i.e., that they should be taken out and shot? > :-) *sigh* I am constantly flabbergasted by what people think of as "important" around here. However, yes, I really can take the hint, and having seen no words of support on this I will revert the change. Hoping I'm running out of nits, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
/usr/src/etc files without $FreeBSD tags
While we're at it: 24$ grep -RL '\$FreeBSD' /usr/src/etc/* /usr/src/etc/amd.map /usr/src/etc/fbtab /usr/src/etc/isdn/isdnd.rates.UK.BT /usr/src/etc/kerberosIV/krb.conf /usr/src/etc/kerberosIV/krb.realms /usr/src/etc/locale.alias /usr/src/etc/master.passwd /usr/src/etc/minfree /usr/src/etc/motd /usr/src/etc/namedb/named.root /usr/src/etc/rc.diskless1 /usr/src/etc/rc.diskless2 /usr/src/etc/sendmail/freebsd.mc /usr/src/etc/termcap.small Having the tags in the files helps mergemaster, if nothing else. :) Thanks, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: make aout-to-elf-build Failing
I've seen quite a few reports of this lately, and while this fixes it, it shouldn't be necessary, should it? Has something changed in the 'make upgrade' target recently? Doug "Andy V. Oleynik" wrote: > > Crist, I had latly same sort of things. > Fix is to define in ur /etc/make.conf MACHINE_ARCH as i386 > MACHINE_ARCH= i386 > Good luck. > "Crist J. Clark" wrote: > > > Doug wrote, > > > "Crist J. Clark" wrote: > > > > > > > > It's a lazy Sunday afternoon, and I am finally thinking of doing the > > > > 2.2.8-STABLE to 3.2-STABLE upgrade. > > > > > > > > I have upgraded within a major release several times (a number of > > > > 2.2.7 to 2.2.8 and 3.1 to 3.2 systems), but never done the a.out to > > > > ELF thing before. However, I really do not think this has anything to > > > > do with my problem. > > > > > > > > I _just_ sucked down 3.2 using cvsup, went into /usr/src, and after > > > > reading /usr/src/Makefile about 50 times, finally typed, > > > > > > > > # make aout-to-elf-build > > > > > > The preferred method is the all-in-one 'make upgrade' target. > > > Trying to > > > make any of the steps individually is not supported. Take a look at > > > http://freebsd.simplenet.com/make-upgrade.html > > > > Thanks for the reference to your webpage; it is helpful... > > > > However, doing a 'make upgrade' dies with the exact same error, > > > > -- > > >>> Cleaning up the aout obj tree > > -- > > . > > [snip] > > . > > . > > ===> lib/libc > > "/usr/src/lib/libc/../libc/gen/Makefile.inc", line 32: Could not find > > /usr/src/lib/libc/../libc/unknown/gen/Makefile.inc > > "/usr/src/lib/libc/../libc/net/Makefile.inc", line 22: Could not find > > /usr/src/lib/libc/../libc/unknown/net/Makefile.inc > > "/usr/src/lib/libc/../libc/stdlib/Makefile.inc", line 23: Could not find > > /usr/src/lib/libc/../libc/unknown/stdlib/Makefile.inc > > "/usr/src/lib/libc/../libc/string/Makefile.inc", line 16: Could not find > > /usr/src/lib/libc/../libc/unknown/string/Makefile.inc > > "/usr/src/lib/libc/../libc/sys/Makefile.inc", line 16: Could not find > > /usr/src/lib/libc/../libc/unknown/sys/Makefile.inc > > make: fatal errors encountered -- cannot continue > > *** Error code 1 > > > > Stop. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: make aout-to-elf-build Failing
On Tue, 31 Aug 1999, John Birrell wrote: > On Mon, Aug 30, 1999 at 09:13:58AM -0700, Doug wrote: > > I've seen quite a few reports of this lately, and while this fixes it, > > it > > shouldn't be necessary, should it? Has something changed in the 'make > > upgrade' target recently? > > `make' has changed. Ok, that's the cause then, so what's the solution? :) And meanwhile is it going to hurt anything if I put a suggestion on my 'make upgrade' web page that users do 'make -DMACHINE_ARCH=i386 upgrade' as a temporary measure to get the thing to work? Thanks, Doug -- "My mama told me, my mama said, 'don't cry.' She said, 'you're too young a man to have as many women you got.' I looked at my mother dear and didn't even crack a smile. I said, 'If women kill me, I don't mind dyin!'" - John Belushi as "Joliet" Jake Blues, "I Don't Know" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
On Mon, 30 Aug 1999, David O'Brien wrote: > > I've had a week-end away from a keyboard to think about this. The only > > reason we have to use case statements for case-insensitive variable > > testing is because sh(1) doesn't offer any upper/lower case handling > > Also so that common settings can be added. Besides "yes" and "no" there > could be other forms of wanting and not wanting. I'm all but done with the rc* files and moving on to the other places in /etc that use test currently. There are 6 states that take 99% of the cases into account: yes no !yes !no presence-of-a-variable absence-of-a-variable Frankly, I'm not sure what the proposed functions get us. Current tools take all of those possible conditions into account, and adding custom hacks for common cases will increase the likelihood of people writing extremely non-portable scripts with them. Maybe I'm missing something though... Also, keep in mind that it's not just case sensitivity that we're working with here. It's also the fact that case is a sh builtin, as opposed to test which is not. If you want to see what I've got so far check out http://gorean.org/rcfiles/ Doug -- "My mama told me, my mama said, 'don't cry.' She said, 'you're too young a man to have as many women you got.' I looked at my mother dear and didn't even crack a smile. I said, 'If women kill me, I don't mind dyin!'" - John Belushi as "Joliet" Jake Blues, "I Don't Know" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: make aout-to-elf-build Failing
John Birrell wrote: > > On Mon, Aug 30, 1999 at 03:55:42PM -0700, Doug wrote: > > > `make' has changed. > > > > Ok, that's the cause then, so what's the solution? :) And > > meanwhile is it going to hurt anything if I put a suggestion on my 'make > > upgrade' web page that users do 'make -DMACHINE_ARCH=i386 upgrade' as a > > temporary measure to get the thing to work? > > The solution is to fix `make'. I could commit the fix, but I'm not > in a position to build -stable just now. I'm not supposed to commit > without testing. The fix looks straight forward though, so "it > should just work". 8-) If all it takes is a make world (as opposed to make upgrade) I can test it if you'll send me the patch. I'm on 3.2-Stable as of 8/8 right now. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: make aout-to-elf-build Failing
On Wed, 1 Sep 1999, John Birrell wrote: > On Tue, Aug 31, 1999 at 08:27:00AM -0700, Doug wrote: > > John Birrell wrote: > > > The solution is to fix `make'. I could commit the fix, but I'm not > > > in a position to build -stable just now. I'm not supposed to commit > > > without testing. The fix looks straight forward though, so "it > > > should just work". 8-) > > > > If all it takes is a make world (as opposed to make upgrade) I can test > > it > > if you'll send me the patch. I'm on 3.2-Stable as of 8/8 right now. > > If you've already upgraded, it's too late to test the patch because > you won't execute the code in question. I had a feeling that I misunderstood you, which is why I asked for a clarification. > Do I really need to send you > a patch to change one word in /usr/src/usr.bin/make/main.c?! Please take > a few moments to have a look for "unknown" in that file. Sigh. "Straight forward" (sic) to you isn't necessarily so to me, especially where issues related to make are concerned. To start with, I wouldn't even have know where to start looking (make code, some other code, *.mk files, make.conf...). If all it took was a simple change you could have said so. Given that someone more knowledgeable than I has already stepped forward, it looks like it will get taken care of anyway, so no sweat. If not, I do have a scratch disk that I can run through the procedure on, and now that I know where to look, yes, the fix is obvious enough. Thanks for your help, Doug -- "My mama told me, my mama said, 'don't cry.' She said, 'you're too young a man to have as many women you got.' I looked at my mother dear and didn't even crack a smile. I said, 'If women kill me, I don't mind dyin!'" - John Belushi as "Joliet" Jake Blues, "I Don't Know" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Minor patches to pwd_mkdb
On Wed, 1 Sep 1999, Mike Smith wrote: > No. Try for a patch that guesses how big the password file is (try > using stat()) and tunes the cache dynamically. > > Hardcoding this at _build_ time is not any sort of "right" solution. Agreed on all counts. I'd also like to add a vote for this since we have multiple machines with 16k user password files. I had intended to start looking at the code and offer a solution instead of a me too, but it sounds like others are already on the right track, so I'll be glad to test something if someone comes up with patches. Doug -- "My mama told me, my mama said, 'don't cry.' She said, 'you're too young a man to have as many women you got.' I looked at my mother dear and didn't even crack a smile. I said, 'If women kill me, I don't mind dyin!'" - John Belushi as "Joliet" Jake Blues, "I Don't Know" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
On Wed, 1 Sep 1999, Sheldon Hearn wrote: > > Hi folks, > > I plan to add a user ``smtp'' with UID 25 and a member of group > ``mail'', for use in running non-priveledged MTA's in FreeBSD. This is > primarily for the convenience of maintainers of mail ports. Why not do this as part of the port itself, ala majordomo? That works just fine and is completely non-controversial because you don't get it unless you ask for it. Doug -- "My mama told me, my mama said, 'don't cry.' She said, 'you're too young a man to have as many women you got.' I looked at my mother dear and didn't even crack a smile. I said, 'If women kill me, I don't mind dyin!'" - John Belushi as "Joliet" Jake Blues, "I Don't Know" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
On Wed, 1 Sep 1999, Nick Hibma wrote: > > > > > Why not do this as part of the port itself, ala majordomo? That > > > works just fine and is completely non-controversial because you don't get > > > it unless you ask for it. > > > > I would just liek to point out that Postfix is also doing the exact same > > thing ... user postfix ... (as well as a group maildrop) > > Maybe a stupid question, but how do you figure out which uid is still > available, if you don't want every port to include a UID scanning > utility? It's not a stupid question at all. There is already such a utility in the majordomo port, perhaps make this its own port and add that as a dependency? We've already been told that postfix (one of the favorite replacement MTA's for our crowd) uses a different name and group, so this proposed change won't help it at all. My point is simply that fixing this problem is the responsibility of the port maintainers. There is no point in adding something to the base system that will only benefit a few people when a mechanism to solve the problem which does not affect people who don't want the port(s) is already available. Doug -- "My mama told me, my mama said, 'don't cry.' She said, 'you're too young a man to have as many women you got.' I looked at my mother dear and didn't even crack a smile. I said, 'If women kill me, I don't mind dyin!'" - John Belushi as "Joliet" Jake Blues, "I Don't Know" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
Sheldon Hearn wrote: > > On Thu, 02 Sep 1999 15:42:56 +0200, Markus Stumpf wrote: > > > The numeric id IS important. > > How do you think NFS maintains privileges across machines? > > I have no idea how NFS works. :-) > > I _do_ know that, if machines across the network need to know about > magical IDs on their peers, then it's nothing like how SMTP works, and > thus irrelevant to the username I think we should add. You can't say on the one hand that there are no rational arguments against your proposal (as you did in another post) and then on the other say that you choose to ignore arguments you don't understand. As I see it there are three groups of people relevant to this change. One is a fairly small group who use exim or postfix as their MTA who would benefit from this change. Next is a group (including myself) who are responsible from maintaining freebsd in heterogenous network environments who would be penalized by this change. With no hard data to support my position I'd say that these two groups are roughly equal. Finally there is a whole big chunk of people for whom this change provides no benefit. So at best, it's a wash, at worst it's a bad idea. > > This also has nothing to do with emotions ... it's my experience from > > the time I worked at the computing staff at the univ, where we had to > > maintain a few thousand users on a few hundred machines of all types. > > The tools which help you add users default to a minimum UID of 1000. If > users have been added with very low UID's, they've been added manually. > This change won't be uncomfortable for people who have their hands that > deep into the system. > > More to the point, though, who cares whether the user's ID is 25 on one > box, 12 on another and 2525 on a third? The _name_ is what we're looking > for, here. As already pointed out, the system doesn't know anything about the names. All it cares about are the numbers. > > In some perspectives ($HOMEs, mail, standard programs, shared document > > space) the machines had to look and feel alike for the users. > > > > We noticed that the predefined uids/gids on the systems were nearly > > useless for that tasks (as they were all different) > > ID's _are_ useless for the task of look'n'feel. That's what usernames > are for. Again, you've completely missed the point. > > If in such an environemt the uid 25 is already used for some other > > service it's a pain to integrate new FreeBSD machines from the > > moment FreeBSD comes shipped with uid 25 allocated to a user smtp. > > I'm not catering for people who create accounts with low UID's and then > try to > > 1) Merge in master.passwd entries from subsequent FreeBSD >releases without using their eyes. > > 2) Install STABLE packages on RELEASE systems. But that's just the problem. You're violating POLA for something that provides no clear benefit, except to a small handful of people for whom there is already an appropriate and painless solution. And ultimately -Stable will become -Release, so your argument here is absurd on its face. Please understand, this is not a personal attack. I'm sure that your proposal was motivated by good intentions, but those of us who see the harm in it and understand the issues involved are trying to explain why it's a bad idea. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
sysinstall nit
Present in -Stable and -Current. If you go to Configure | Distributions | src and attempt to choose All, the src distribution never gets selected and nothing gets installed. I can send a PR if needed, but it's such a small thing I didn't think it would be worth it. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
/etc sh script cleanup ready for testing
The long-awaited moment (well, by me anyway) has arrived. Except for the files in /etc/periodic I have finished the cleanup of the /bin/sh scripts in /etc. I've followed the style guidelines requested by the majority of -hackers, so I hope that I've made everyone as happy as possible here. You can find the files at http://gorean.org/rcfiles/ I've tested as much of this stuff as I can here, but I don't have some possible options; like an alpha, pc cards, isdn, ppp, etc. I have been extremely careful in my changes however, so I'm confident that you can employ these patches without fear of system mangling. In addition to the previous comments, here are the notes I made while working on this: 1. A few files had no $FreeBSD tag, so I added them. 2. Lots of (spurious?) double spaces in rc.serial. 3. In rc.alpha and rc.i386 some of the one-line comments can probably be deleted. 4. There are a number of gratuitous punctation diffs between etc.i386/MAKEFILE and etc.alpha/MAKEFILE. 5. rc.network.S* is Sheldon's work, my thanks to him for doing the first pass on that file. (Of course, final responsibility for any errors is mine alone.) 6. In rc and rc.network I provided the defaults for *_program variables to avoid a possible case of user foot shooting. In the case of files with heavy white space changes you might find it easier to isolate the significant changes by saving the file and doing a diff -[uc]Bb between it and the current version. At some point in the future I plan to start on the periodic scripts, if no one gets there first. However, I'd like to submit these now for testing/committing partly so that they don't get stale, and partly because if I don't take a break and start working on something else my brain is going to explode. :) All of the patches are up to date as of tonight's -Current. Any questions, comments, suggestions, or what have you are welcome of course; although I'm really hoping that too many changes are not called for since that was the purpose of asking for review ahead of time. I'll have some freebsd-hacking time tomorrow if there are any more nits to be picked. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 2.2.8 - can't mount root
Darren Reed wrote: > > Is there a way to get FreeBSD 2.2.8 to ask you for the root device > rather than have it attempt to mount and fail ? The 3.x branch is a lot smarter about this, but I agree that it would be nice in those situations where it still can't find it to stop and ask rather than just panic(). Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: /etc sh script cleanup ready for testing
Michael Reifenberger wrote: > > Hi, > On Sun, 5 Sep 1999, Doug wrote: > ... > > can find the files at http://gorean.org/rcfiles/ > looks good so far. > I'm missing rc.serial in rcfiles. Thanks for the reminder. I didn't make any changes to that file because there weren't any [/test lines in it, and there were enough oddities that I felt like I'd be better off leaving it alone. Someone with more knowledge about it and more ability to test the results could probably do some good there. > BTW: please make the rc* files be self contained (where it makes sense) so > that > they can be called outside of rc. Each file should include rc.conf for itself > so that one could reinit the serial lines by `sh /etc/rc.serial` or fire up > isdn after reconfiguration with `sh /etc/rc.isdn`... I am not opposed to this change, however A) It's fairly huge, B) It's extremely controversial, given that it makes us more like SysV, and C) I don't care enough about it to fight the requisite battles. If I _were_ inclined to do something like this I'd start small, and start submitting patches. Personally I kind of like some of the scripts sun has where you can do 'nfs_script start' or 'nfs_script stop', etc. It makes things easier on long-running systems. Thanks for your feeback, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: How to prevent motd including os info
"Rodney W. Grimes" wrote:
>
> > [moving to -hackers]
> [I'm going to loose the rest of this thread since I am not on hackers :-(]
Shame on you. :)
> > "Rodney W. Grimes" writes:
> Actually I would like _all_ the output from /etc/rc* to be avaliable
> after boot.
One of the things discussed on -hackers recently is my rc* (et al)
cleanup
effort. You can see the results at http://gorean.org/rcfiles/. If I can get
the current set of patches committed the next step in my proposal is to
change as many of the 'echo' statements as humanly possible to use 'logger'
instead. This is somewhat controversial because it will (for some items)
require moving 'logger' to /bin, but I think it's worth it.
> This would be a big win for remote admining and trying
> to figure out what went wrong during the last boot without having to
> drive down and hook up a console of some form. I know we could hang
> serial consoles on all of them, but why spend money on hardware when
> the problem can be solved with software :-).
I agree, both that it would be a huge benefit for remote admins (I'm one
too) and that there are some problems that a serial console doesn't solve
where having a hard copy is your best bet (such as jr. asst. cow orker
rebooted a machine he should not have, and now it's borked and no one knows
why).
> > fsck_output="$(/sbin/fsck -p)"
> > /sbin/mount -at nonfs
> > echo "${fsck_output}" >/var/run/fsck.boot
> >
> > but then you wouldn't be able to see the output while it runs. The
> > only solution I can think of is the following:
> >
> > fsck_output="$(/sbin/fsck -p | /bin/tee /dev/console)"
> > /sbin/mount -at nonfs
> > echo "${fsck_output}" >/var/run/fsck.boot
> >
> > but I don't expect people to be happy about moving tee(1) from
> > /usr/bin to /bin.
Another possible solution to this would be giving fsck a flag to copy
it's
output to a file, STDOUT, or what have you. Since the rest of the cases
could be handled with 'logger' and/or redirction we wouldn't have to bring
'tee' into /bin.
Doug
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: How to prevent motd including os info
"Rodney W. Grimes" wrote: > It dawned on me what can be done. Look, we get all the kernel printf's > from the dmesg output saved in a buffer and pull that out later with > syslog, looks like we could just slip a pipe fitting into /dev/console > that copies all it's output into the mesgbuf as well, until we smack it > wth the ballpean and tell it to stop doing that (Either getty lanching the > login: on ttyv0 could cause this, or something at the end of /etc/rc). > > What do you think of that idea? I think that's a fine idea, and it's a lot cleaner than mine for a number of reasons. Completely beyond me to code, but very nice from the design standpoint. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: panic() the system from the console (was: Re: kern/13721: There is no way to force system panic from console)
> As the originator suggested in his subsequent posting to the PR > database, we can defined "panic" key and handle it in syscons > as follows: Would not the 'panic' option in DDB be enough to handle this, or am I missing something? I'm not opposed to adding a panic() key combo, just wondering if it's duplicating existing technology. Doug -- "My mama told me, my mama said, 'don't cry.' She said, 'you're too young a man to have as many women you got.' I looked at my mother dear and didn't even crack a smile. I said, 'If women kill me, I don't mind dyin!'" - John Belushi as "Joliet" Jake Blues, "I Don't Know" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: GNU GLOBAL
You state that you have made up your mind about this decision, so I won't try to persuade you otherwise. I do think that there are some things that you should think about though. Shigio Yamaguchi wrote: > > I'm the author of GLOBAL source code tag system. > > I have decided to release next version of GLOBAL as a GNU software. > It means that it will be released under GPL instead of BSD license. Have you consulted an attorney about this decision? Are you sure that you understand everything that this decision means? Do you realize that by going with the GNU license you seriously hurt any chances you might have of ever making any money off of your product? > This decision was made by practical reason, not by doctrine reason. > It is advantageous for GLOBAL, because > > o GNU softwares are distributed to widespread environments. I can't argue with this point. However with the growth of popularity of the various *BSD's, that market is becoming more "widespread" as we speak. [snip] > That makes it easy for GLOBAL to reach the goal, that is, becoming > a common source code tag system in various environments. Hmmm... Well if your goal is to have a lot of people using your product, in the short term going GNU is probably right. However, if you achieve your goal, but your software is under the GNU license, what does that get for you? > Since FreeBSD already includes GNU softwares, it seems no problem. > GLOBAL itself will be as it be. I agree with the previous poster that our stated goal is (and should be) eliminating as much GNU licensed software from the FreeBSD base as possible. To my (albeit limited) knowledge nothing in the base depends on GLOBAL, so I would be one of those who would be calling for its removal from the base. Of course, a port of your program would be welcome, and in fact if you are already settled in this decision you should start working on a port now and beat the crowd. > I'm concerned about whether or not FreeBSD community accept GNU GLOBAL. > I hope you not to reject it, because the rejection splits GLOBAL and it > makes it hard for GLOBAL to be a common source code tag system. But that's YOUR goal. Our goals are different, and the GNU license interferes with the goals of the FreeBSD project. Unfortunately we have come to the point in time where those in the GNU camp have as their stated goal the destruction of all other types of software licensing. It is sad that people who should be working together to create the best tools possible instead have to waste time with rhetoric and political maneuvering. However, things are what they are. The likelihood of being accepted by the GNU people is much smaller if you use a BSD license. At the same time, by using a GNU license you prevent the BSD people from accepting you at all. Of course, at this point in time such things as gcc are necessary evils, however as already stated many of us are working on making them less necessary. Your tool isn't "necessary" for anything at all at this point, therefore it's easily disposed of. I am sorry if my words sound harsh or argumentative, because that is not my intention. For all I know, you product could be the best thing since sliced bread. However the current state of the political aspects of software development is what it is, so we are better served by not ignoring it. Good luck, Doug (who speaks only for himself) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Heavily loaded nfs/amd gets stuck
Shaun Jurrens wrote: > Studded, you might try to look at /usr/share/doc/handbook/nfs.html. It might > help to use a high quality network card and maybe track the traffic between > the boxes to see if the mentioned packet problems show up. It's an Intel motherboard with an Intel Pro 100 built on, plugged into one of two high quality switches running at 100 and full duplex, so I doubt that is the problem. :) I could sniff the traffic, but what would I be looking for? Every DDB backtrace dies in mount() so I am inclined to think it's not a packet problem, but I would be willing to look at just about anything at this point. > Just thought you might have missed the obvious. *Nod* That's always a possibility, NFS is definitely not my thing, although I'm learning more and more about it as I go along. :-/ Thanks, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Inetd and wrapping.
Sheldon Hearn wrote: > > On Mon, 21 Jun 1999 14:13:49 +0100, David Malone wrote: > > > I got one person who suggested a flag in inetd.conf which could disable > > wrapping for a service. This seems like quite a good idea if we can come > > up with an acceptable syntax for the flag. > > What I have in mind is a -w option. Specified once, it disables wrapping > of internal services. Specified twice, it disables wrapping altogether. E > It's a pity we went forward the way we did, making wrapping the default > for STABLE. When exactly was it made the default? Prior to 3.2-Release, or after? > I'd have preferred leaving it disabled by default, for > maximum backward compatibility. However, now that we're here, I think > it'll be a very confusing move to make non-wrapping behaviour the > default. It's never (ok, rarely) too late to undo a bad decision. If the change happened after the latest -Release, by all means, back it out. Very few users adopt -Stable compared to the number of users who adopt releases. If the change happened prior to the release, we're stuck with it for all practical purposes. > There's already a flag in inetd.conf called inetd_flags, in which the > administrator could place her "-w" or "-w -w" as desired. It would be more traditionally unix-like to have a flag for wrapping a service (on by default, or not, see above) and a flag for not wrapping. For instance I could start inetd with the -w flag to wrap all services, and then disable one service with a -d for don't wrap, and vv. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
[Fwd: Re: misc/11796: Bad lines in 3.2-RELEASE inetd.conf]
Since y'all are discussing inetd.conf, here is something else to consider. Doug Original Message Subject: Re: misc/11796: Bad lines in 3.2-RELEASE inetd.conf Date: Wed, 16 Jun 1999 12:55:43 -0700 (PDT) From: Studded To: Dag-Erling Smorgrav CC: freebsd-b...@freebsd.org, freebsd-gnat-sub...@freebsd.org,a...@wnm.net On Wed, 2 Jun 1999, Dag-Erling Smorgrav wrote: > The following reply was made to PR misc/11796; it has been noted by GNATS. > > From: Dag-Erling Smorgrav > To: a...@wnm.net > Cc: freebsd-gnats-sub...@freebsd.org > Subject: Re: misc/11796: Bad lines in 3.2-RELEASE inetd.conf > Date: 01 Jun 1999 16:26:46 +0200 > > a...@wnm.net writes: > > The default /etc/inetd.conf contains commented out lines for enabling > > identd. Both relevant lines refer to the 'ident' service, which is, > > according to /etc/services, really 'auth', as it should be. > > Oh? > > r...@des ~# grep -w 113 /etc/services > auth113/tcpident tap#Authentication Service > auth113/udpident tap#Authentication Service > Works just fine, thank you very much :) The man page for identd says in part, The service-name entry is the name of a valid service in the file /etc/services. For ``internal'' services (discussed below), the service name must be the official name of the service (that is, the first entry in /etc/services). Therefore the first entry should definitely be changed. The second entry in the inetd.conf file is for a non-internal identd daemon, but some versions of the software are more picky than others, and the fact that one of them might "work" doesn't mean that the configuration file isn't in error. At minimum the following patch should be applied. Ideally you would add a comment to the fact that the two entries in inetd.conf are mutually exclusive. Thanks, Doug --- inetd.conf.Dist Sun May 9 06:31:40 1999 +++ inetd.conf Wed Jun 16 12:49:51 1999 @@ -65,11 +65,11 @@ # # Return error for all "ident" requests # -#ident stream tcp nowait rootinternal +#auth stream tcp nowait rootinternal # # example entry for the optional ident server # -#ident stream tcp waitkmem:kmem /usr/local/sbin/identd identd -w -t120 +#auth stream tcp waitkmem:kmem /usr/local/sbin/identd identd -w -t120 # # example entry for the optional qmail MTA # To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-bugs" 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: [Fwd: Re: misc/11796: Bad lines in 3.2-RELEASE inetd.conf]
On Mon, 21 Jun 1999, Sheldon Hearn wrote: > > > On Mon, 21 Jun 1999 08:02:14 MST, Doug wrote: > > > The service-name entry is the name of a valid service in the file > > /etc/services. For ``internal'' services (discussed below), the > > service name must be the official name of the service (that is, the first > > entry in /etc/services). > > Read the services(5) manpage. There's nothing wrong with using a > service's alias. Can you point out exactly what part of the man page that you are referring to that contradicts what the inetd man page says? Have you checked the actual code for inetd to verify that it will work with services aliases? In my experience, and in the experience of the PR poster it *is* necessary to use the canonical name of the service, however if you can check the code, test it thoroughly and determine that inetd works perfectly well with aliases, then feel free to change the man page for inetd. Thanks, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: Re: misc/11796: Bad lines in 3.2-RELEASE inetd.conf]
On Mon, 21 Jun 1999, Sheldon Hearn wrote: > On Mon, 21 Jun 1999 11:12:26 MST, Doug wrote: > > > Can you point out exactly what part of the man page that you are > > referring to that contradicts what the inetd man page says? Have you > > checked the actual code for inetd to verify that it will work with > > services aliases? > > Certainly. From services(5): ... Quoting the part of the man page that says there are such a thing as aliases does not refute the part of the inetd man page that says even though there are such a thing as aliases, you can't use them for internal services. > > In my experience, and in the experience of the PR poster it *is* > > necessary to use the canonical name of the service, however if you can > > check the code, test it thoroughly and determine that inetd works > > perfectly well with aliases, then feel free to change the man page for > > inetd. > > Since the manpage supports my experience thus far, I really can't see > how you'd put the burden of proof on me. :-) You are really really missing my point here, so I will state it again. If you have carefully examined the code for *every* case of *every* internal service, and you have tested it thoroughly, and you are 100% sure that the man page is in error, change the man page. If all of the above is not true, you should change the example for ident in the sample conf file because even IF it works, even if it works *100%* of the time for YOU, there is an outstanding PR that shows it doesn't work for everybody, and there is absolutely no justification for leaving an example in the conf file that conflicts with the man page. (No justification other than the ubiquitous, "We've always done it that way.") I sincerely hope that I've made myself sufficiently clear on this. If you are still confused, please feel free to respond. Thanks, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: Re: misc/11796: Bad lines in 3.2-RELEASE inetd.conf]
On 21 Jun 1999, Dag-Erling Smorgrav wrote: > Doug writes: > > You are really really missing my point here, so I will state it > > again. If you have carefully examined the code for *every* case of *every* > > internal service, and you have tested it thoroughly, and you are 100% sure > > that the man page is in error, change the man page. > > The confusion arises from the fact that inetd and /etc/services > disagree on what the canonical name for the ident service is. Inetd > has these canonical names hardcoded in an array of structs, so > changing the canonical name in /etc/services does not affect inetd's > belief of what the canonical name is. Ok, so what we're looking at is actually an entirely different error. :) In fact, the man page is correct, however the inetd code currently has an outdated version of the canonical name. Thus, at minimum the man page should be udpated to reflect this reality. A better solution would be to remove the hard coded values in the code, and fix the config file. It adds unneeded steepness to the learning curve to have the man page and the example configuration file out of synch. The average new user would have no reason to check the code to get an answer to this. Thanks, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: Re: misc/11796: Bad lines in 3.2-RELEASE inetd.conf]
On Mon, 21 Jun 1999, Sheldon Hearn wrote: > > > On Mon, 21 Jun 1999 11:42:46 MST, Doug wrote: > > > [...] there is an outstanding PR that shows it > > doesn't work for everybody, and there is absolutely no justification for > > leaving an example in the conf file that conflicts with the man page. > > Doug, I'm annoyed that you ignored the most important part of my > previous mail. What I quote you on having said above is not true There > is no outstanding PR that shows anything at all on this issue. The PR > you're talking about is 100% content-free. "It doesn't work with the conf file that came with the system, but it does work if I change the conf file to match the documentation" is pretty good content in my book. Obviously he doesn't include information on how to repeat the problem in a verifiable way, but that doesn't (in my book anyway) invalidate the PR. > I'm particularly keen in seeing inetd as bug-free as possible, so I urge > you _again_ to produce a meaningful "How-To-Repeat". I urge you, again, to try and understand my point. There is no reason to have the man page and the example conf file out of synch. Also, as Dag-Erling pointed out, the real problem is much deeper than either, however bringing the documentation up to date *should* be a priority regardless of how many of the other problems you choose to fix. > > (No justification other than the ubiquitous, "We've always done it > > that way.") > > This is an aside, but it's worth noting. A comment like that makes it > sound like you underestimate the time a sysadmin saves by knowing "the > way things have always been". Don't be ridiculous, the two things have nothing to do with one another. You're trying to justify perpetuating an error as a time saver to people who already know better, and I'm trying to point out that new users shouldn't be hampered by this kind of nonsense. Fix the man page, the config file AND the code and no one will be inconvenienced because it will all work the way it ought to. > In this particular case, note that both OpenBSD and NetBSD ship with an > inetd.conf that uses the service name "ident" instead of "auth". Even if they were doing everything right, you're still tossing in red herrings. My point is not about whether it works, my point is that the documentation should be consistent with reality. Whether we're talking about an ideal reality or not is a whole other story. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Inetd and wrapping.
Sheldon Hearn wrote: > I used to pride myself in my communication skills, but I'm starting to > doubt myself. :-) It's not that we don't understand you, it's that we don't agree with you. There is a HUGE difference. > My concern is that what you want introduces duplicate functionality. You keep saying, "but you can do something like what you want to do with tcp wrappers," but others are saying, quite clearly that they want to be able to COMPLETELY bypass tcp_wrappers altogether. Configuring tcp_wrappers for a specific case is very different from not having to configure it at all. > 1) Performance. > >I think we're all clear now that exclusion options will not >introduce a significant performance gain. We've already >scored our performance gain by obviating an exec on tcpd. By excluding tcp_wrappers you're also excluding the overhead to check the hosts.allow file. On a heavily loaded service this can be considerable. > It's critical that folks understand that built-in wrapping in inetd is > not the same as inetd passing the job of wrapping to a program called > tcpd. Something different is happening in each case. It just so happens > that the two cases share a common goal. Actually, the same thing is happening, just in different places. > When you say you want "functionality that exists with TCP wrappers", I > think you mean "identical semantics to those used with tcpd". You can't > have it, it's that simple. As long as you acknowledge that in this case, "You can't have it" is a design decision, and not everyone agrees with your concept of the design. Personally I don't care enough about it to write the patch, but that won't stop me from registering an objection since you seem to be assuming that silence == assent. > What you should be able to have is the same functionality as was > available when using tcpd. I don't think the fact that you may need to > set things up differently to achieve the same results as you had before > isn't a serious problem, because you're doing a different thing now. That's because you're looking at this from the standpoint of a developer who is deeply involved in the code on a daily basis. You need to start thinking of things in terms of the much more common case, the casual user who will be going from say, 3.0-Release to 3.3-Release without reading any of the documentation. Why should this user have to either go out of his way to fix something that wasn't broken, or find a critical service disabled when he reboots just because no one could be bothered to make the new interface compatible? As far as I'm concerned the system should ship with per service toggles, and all of them toggled off, with a hosts.allow with nothing but "ALL : ALL" in it. But then again I've been called overcautious. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, Karl Denninger wrote: > On Thu, Jun 24, 1999 at 01:23:19PM +0930, Mark Newton wrote: > > Karl Denninger wrote: > > > > > I've found FreeBSD to outperform NT-anything in any task you throw at the > > > machine from web service to Samba for file and print service for PCs > > > running Windows. > > > > Granted. Perhaps we're seeing an artifact of NT's developers focussing > > on optimizing their system for good benchmark performance rather than > > good real-world performance. > > > > 'twill be interesting to see the offical report to find out where the > > various strengths and weaknesses really are. > > > >- mark > > Yes. > > One place where we *ARE* weak is N-way (more than 2-way) SMP systems. I'm > not at all sure why this happens, but I suspect that a big part of it is > concurrency issues within the kernel and filesystem. > > BUT - for most REAL applications that configuration is a lose. For example, > for a big web server I'd prefer 4 boxes and 4 IP addresses (round-robin) > than one big box with a 4-way SMP system. Why? Because I get both better > performance that way AND redundancy - if one box fails, I still have > three more, all of which are working. If one box fails in a 4-way > SMP configuration I have nothing at all. We're adding some machines at work for (essentially) cgi processing only. It was never considered to use anything less than 2 cpu boxes, and the current round of testing is going so well that we're seriously considering 4 cpu boxes because they are not that much more expensive and our processing is highly CPU bound. I agree that redundancy is a good thing, but at some point the increased network latency exceends the point of diminishing returns for the redundancy factor. In short, increasing SMP efficiency should really be a priority for N>2 systems. > I had an NT machine that ran file and print service for my office (before > I sold the company). I replaced it with SAMBA on the same hardware. > > Performance more than doubled, and the ONLY thing that I changed was the > operating system. Originally we were going to go with linux exclusively on this project, both because that's the only Intel unix my co-workers were familiar with, and based on recommendation from our proprietary CGI vendor. After weeks of soft soap I convinced my boss to use freebsd on one of the two boxes. Linux kicked our ass on the benchmarks for this program, mostly do to the "optimized idle loop" that was discussed here a couple of weeks ago. They beat us by 35% on the disk access/database tests, but I was able to get that down to only a 15% advantage if I went async. Fortunately my boss wasn't concerned about this test because the box is going to do 99% of its disk access over NFS, but... I told my boss (and he agreed completely) that benchmarks are not the same as real performance, so I was hoping to impress him with freebsd's stability and better performance in the real world application. And to a certain extent, I have, since when my box is running it's load average is consistently less than 1 while the linux box' load average is consistently over 5 with exactly the same number of requests. So, points for me on performance. However notice I said, "when my box is running." So far it's fallen down on NFS issues so many times that it's currently sidelined. The Linux box has been running for almost a week, and is currently handling the load for my box too. My boss has been patient, but he made the comment the other day that "so far freebsd is way ahead on the hassle factor" so I'm not sure that my part of the experiment is going to last much longer. Now if we were talking about a uni-processor system doing nothing but serving web pages from local disk, I know I'd be kicking some serious ass, but that model isn't the real world anymore. Especially as Network Appliance boxes become more and more common (and they will be, fast and furious) multi-processor and NFS are for all practical purposes already the reality now, and will only be more so in the future. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, Karl Denninger wrote: > On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote: > > In short, increasing SMP efficiency should really be a priority > > for N>2 systems. > > Agreed. But this is a BIG job, because to do that you have to solve the > "one big kernel lock" problem and go to fine-grained locking. This is a > non-trivial job. No argument there. My point was more in support of the people who were demonstrating how other platforms are kicking our ass. Responding with, "Yeah, but if you limit yourself to the specific case where freebsd performs well, we rock!" doesn't cut it. > > However notice I said, "when my box is running." So > > far it's fallen down on NFS issues so many times that it's currently > > sidelined. > > What release are you running? Started with 3.2-Stable, moved to -Current to get the latest and greatest NFS fixes, the problem is that most of the fixes are for the server, and my box is an amd/nfs client connecting to sun (almost all 2.6) servers. I've posted rather voluminously on this topic to both -current and -hackers over the past two weeks, but I've stopped doing that because I have nothing new and I haven't gotten any responses in a while. I just checked the archives and a search on those two lists for "heavily and loaded and amd" brings up the threads. I'm actually building world right now to get the latest NFS patch just in case it helps, but I'm not sure how much longer we (my department) can justfiy the expense of me fiddling around with this because we already know that the linux box works. > > Now if we were talking about a uni-processor system doing nothing > > but serving web pages from local disk, I know I'd be kicking some serious > > ass, but that model isn't the real world anymore. Especially as Network > > Appliance boxes become more and more common (and they will be, fast and > > furious) multi-processor and NFS are for all practical purposes already > > the reality now, and will only be more so in the future. > > That's the world I lived in (except that I used FreeBSD for the NFS > servers as well!) and done properly it works EXTREMELY well. I'm not going to have that luxury, and I really believe that NetApp and it's cousings are going to be THE point of access in the next year or so. They work too well to pass up, and now that they are OEM'ing the disk shelves they will be too cheap to justify rolling your own for all but the most diehard platform advocates. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Serial Console Wierdness
On Tue, 22 Jun 1999, Aaron Smith wrote: > (also see http://www.arctic.org/~aaron/tips/freebsd-serial-console) Great page, thank you. One suggestion I have is that you make the distinction between getting a login prompt on the com console and getting the boot messages to display on the com console more clear. The fact that those are two different things was not clear to me at all when I started working on this, and it's kind of an important distinction. :) Also, you might consider listing the getty stuff first. It's a lot easier to set that up and debug it since you don't have to keep rebooting, and once that's working getting the boot messages to display should be cake. Finally, you might want to mention that reading /usr/src/sys/i386/boot/biosboot/README.serial is a good idea, even though I wish that file had more details. :-/ I have a couple weird cases that I'd like to solicit comment on. First, I'm hooking up a new FreeBSD machine to the digiboard serial terminal at work. Everything works at 9600, including the bios boot messages from the Intel N440BX mb which supports serial console redirection. The problem comes when I try to raise the speed to 38400. The bios messages come through just fine at that speed, so the serial port and the digiboard support it. Also, if I have a keyboard plugged in, I see everything on the console that I should, and I get the login prompt. But when I unplug the keyboard and the -P option in /boot.config kicks in, the console messages come out in high ascii and even the getty prompt is scrambled. I took the following steps: edit /etc/make.conf rebuild boot blocks change my cuaa0 to std.38400 in /etc/ttys (ttyd0 didn't work with the digiboard) change digiboard speed to 38400 reboot I also tried the CONSPEED option in the kernel config (this is a -current system) still no joy. If I downgrade everything back to 9600 I'm back in business. I'm not sure if it should make a difference, but my cable has only 3 pins, Transmit and Receive crossed, and Ground linked directly. Also, the bios boot output and the digiboard both have XON/XOFF enabled, the rest of the options are the defaults. Yes I know that the obvious answer is "run it at 9600" which is ok with me, since we don't use the comconsole very often. However I find it kind of disturbing that it doesn't work at 38.4. :-/ Weird case number 2 is my two home machines. I've been trying to get a serial console going at home for months with no luck. Your suggestion of using kermit on both boxes has lead me in the right direction, so I'm more hopeful, but I'm still seeing weirdness. The headless (well, the old monitor is attached, for now but no kb) server is "slave," and my workstation is "Master." I have a commercial null modem cable connected to com1 (cuaa0) on slave and com2 on master. (Which reminds me, I think that one or the other of your kermit command lines needs to be changed, since generally you don't want to connect to com1 on both machines. :) When I type in kermit on master, I get nada, not even a local echo. When I type on slave it gets passed to master, but it's all scrambled. Sometimes it's alpha chars, sometimes it's all numbers, and sometimes it's high ascii, depending on how I set the flow control, speed, parity, etc. FWIW, slave is a very old (almost 5 years now) former P 90, now running an intel overdrive chip at 150. I overclocked this machine for years, but I stepped it down just in case that was the cause of my problems. Master is a shiny new box I built from scratch, using an Asus P2B mb, Celeron 300a, etc. I also overclocked this box when I built it, but also stepped it down for this. I have 2.2.8-Release on slave, -current (and formerly -stable, that didn't work for this either) on master. I tried to upgrade slave to 2.2.8-stable last night just in case, but the build failed (still working on that). I do plan to upgrade that box to 3-stable, but I can't do that yet. The immediate suspect is the cable, but when I built my own cable with just TR & G, I got the same results. I bought the commercial grade null modem cable thinking maybe I screwed something up, but it's no better. These are 9 pin serial ports on both boxes. I have no serial devices on slave, and a modem on master but it's set to com3, and I only use it in windows (master is a dual boot box). I'm wondering if the overclocking on the old P90 for so many years might have fried the uarts or something else related to the serial ports? If so, would getting an ISA serial port card and making that my serial console help any? I haven't tried making com2 my serial console yet, is that worth trying? I'm also going to get some new plugs/cables/etc. this weekend so that I can give making my own cable another
Thank you Peter!! (Was: Heavily loaded amd/nfs... )
I am very happy to report that with the recent commits to -current I can now run my script that reads some 16000 small files in over NFS links at full speed and to completion without locking the box. *BSEG* Many, many thanks for this, it was a huge area of concern for my boss that even though the box performed well under real world load it was falling down on this step (building configuration files). Chalk one up for the good guys. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: bpfilter -> bpf patches [LONG]
Dag-Erling Smorgrav wrote:
>
> [Bcc:ed to net, committers; please follow up on hackers]
>
> Attached are patches for renaming 'pseudo-device bpfilter' to
> 'peudo-device bpf', courtesy of glimpse(1) and ed(1). LINT and GENERIC
> build fine with these patches; I haven't tried to run a kernel built
> with them, though. Also, although I caught and corrected a few spacing
> nits caused by chopping off five letters, there may be some I didn't
> catch.
>
> If no-one objects, I'll commit this to -CURRENT in a few days.
Forgive me if this is a stupid question, but are there any circumstances
where naming the kernel include file "bpf.h" would conflict with
/usr/include/net/bpf.h?
In any case, this is a long overdue, and welcome change. Thank you. :)
Doug
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: login problem:
For future reference, questions of this sort should be directed to freebsd-questions, not freebsd-hackers. Gustavo V G C Rios wrote: > > My login.conf classes does not work, i have already looked for into The > Complete FBSD, man pages, /usr/src/lib/libutil/* but nothing works the > way i wanna. > I have a user that belong to shell shell login classes, but he is not > disconnected after 1 minute of idle time? Not all of the login class items work the way they are supposed to. You should probably look at 'idled' in the ports collection. Good luck, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rtfm' script
I'm confused about this script. How does it differ from 'apropos'? Feeling a little dense, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rtfm' script
On Tue, 6 Jul 1999, Brian F. Feldman wrote: > On Tue, 6 Jul 1999, Jordan K. Hubbard wrote: > > > > Which can be disabled in the bash port before the next release... > > > > No, that's a really stupid idea. > > Thanks! But still, I don't think rtfm is very appropriate... Can we look > for something better, more obvious? Or perhaps it would be in the motd > like /stand/sysinstall is people would need to be aware of this. I think your logic is faulty here. There are already many adequate resources in the motd, but your argument for the 'rtfm script' presupposes that the person has not looked at the motd, because if they had they wouldn't need the script. Honestly, while this is one of those things that sounds good when you first start talking about it, in practice I don't see what we gain from it. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rtfm' script
On Tue, 6 Jul 1999, Alex Zepeda wrote: > On Tue, 6 Jul 1999, Brian F. Feldman wrote: > > > RTFM isn't a newby-apparent term. Name it help(1). > > Sure it is. Some hapless newbie wanders into #FreeBDS on efnet, and asks > an already answered question. Aside from a kick, and a possible ban, > they're likely to be met with a chorus of "rtfm", which in all likelyhood > would prompt the inquisitive newbie to try and run rtfm. So the whole script is the punch line to a bad joke? I'm all for improving user documentation, but I keep getting mixed answers as to what this script is for. One answer is that it's so people will have something to do when they are so new and foolish as to believe that 'rtfm' is a command, the other answer is that this script/program/whatever is designed to do a bunch of help file searching that the user could (and probably should be) do themselves. I'd like to make a suggestion which might help both goals, and save some time. Instead of making a program to do the searching for the user, why not write a man page for 'rtfm' that describes the many resources available and how to use them? Then the actual rtfm command could be a short program that just calls up the man page. It's not as glamorous, but IMO it will be more useful. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
