Re: ps on 4.0-current
In message [EMAIL PROTECTED], Warner Losh writes: Not all will agree with this, and it is a change from the past so there needs to be a sysctl to control this. And given that it is a radical change from the past, it needs to default to open. Now, I can't tell if you wore the security-master hard-hat in this email or not, and I see some quite divergent australian positions, so I will sit tight until I see a little bit more of a consensus. Poul-Henning -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
Warner Losh wrote: In message [EMAIL PROTECTED] Poul-Henning Kamp writes: : Warner ? [.. reasons for and against ..] Not all will agree with this, and it is a change from the past so there needs to be a sysctl to control this. And given that it is a radical change from the past, it needs to default to open. Warner Without wanting to get "please send patches" (I fear sysinstall as much as anyone), I think it would be really nice to create a place where we can set a default 'security profile' or something which arranges for these sorts of things to be set according to the role of the machine. For example, in "workstation" mode, the reasonable default is "open", because typically there is one user on the box (other than root) and that person has root access. Excessive hiding info from that user just means that they'll have to use root more, or will give up the idea of using a mortal user entirely and run everything as root (a Really Bad idea, think of Windoze and viruses etc etc). In a dedicated server role, again it might be appropriate to default it to "open" (dedicated server being something like a squid box), again there will be a couple of sysadmin type users or people who have to monitor things. Hiding information gains nothing there either. In other roles, including something like a shell server box with presumably hostile users (you reasonably have to assume this), you want everything you possibly can to be locked down. Oh for ACL's, privilige attributes, etc. It would solve this sort of thing nicely so that you could allow admin users to see what's going on (including a ps -ax and see what the users are running) without having to constantly (ab)use root and the dangers of overusing that. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
On Wed, 24 Nov 1999, Doug Rabson wrote: We need to put audit tags into the source tree when a file is audited. That allows the diffs to be audited later which should be a smaller job and then the audit tag slides forward. Not to interrupt in the middle of this discussion but you might want to check with robert watson before you guys get too deep here since he is working on a FUNDED Posix.1e implementation for FreeBSD. And has already posted some EARLY MAC code. It might be usefull to work with him as well. Just a thought. Chris -- "I've always been mad, I know I've been mad, like most of us have. And you have to explain why you were mad, even if you're not mad." -PF DsoTM ===| Open Systems FreeBSD Consulting. FreeBSD 3.3 is available now! | Yahoo Messenger ID: opsys_98 ---| 1402 N. Washington, Wellington, KS 67152 FreeBSD: The power to serve!| E-Mail: [EMAIL PROTECTED] http://www.freebsd.org | Consulting, Network Engineering, Security ===| http://open-systems.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
hi, MM I have been charged with the duty of ensuring that FreeBSD gets a MM security audit that has the credibility of OpenBSD's. What's going on with FreeBSD Auditing Project (http://www.FreeBSD.org/auditors.html) ? Is it still alive ? I think this task is task of this project members. Or will be ;-) MM I'll get a mailing list going if this is deemed necessary. audit-*@FreeBSD.org ? Or create general list [EMAIL PROTECTED] ? -- /* Alexey Zelkin[EMAIL PROTECTED]*/ /* Tavric National University [EMAIL PROTECTED] */ /* http://www.ccssu.crimea.ua/~phantom [EMAIL PROTECTED] */ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
At 1:41 AM -0500 1999/11/24, Brian Fundakowski Feldman wrote: Our code doesn't run an a system _anything_ like that. That may well be true today, however as FreeBSD gets more widely ported to other platforms, and as the "native" platforms it runs on progress, this might change in the future. I'd suggest erring on the side of paranoia in this case. -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, [EMAIL PROTECTED]Belgacom Skynet NV/SA |o| |o| Systems Architect, News FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ST-506, ESDI and BAD144 ?
Sørens new ATA driver can handle all IDE disks as far as has been tested now, but it doesn't provide bad sector remapping which is needed for ESDI and ST-506 disks. Having two drivers fight for the same class of drivers is a rather messy process, and it complicates the code a fair bit, not to mention the clutter in end-user documentation. Considering that most of the machines with ST-506 and ESDI disks are limited to 16MB ram anyway, I think it would be reasonable to simply tell the users of these old irons to stick with the 3.X branch until end of life (there is probably at least 1.5 years more life in the 3.X branch judging from the history of the 2.2.X branch). So I would like to propose that we discontinue support for ST-506, ESDI disks and BAD144 bad-sector remapping starting with the 4.0 release. So, is anyone running -current on ESDI or ST-506 disks in actual applications (as opposed for the gadget/novelty thrill or testing purposes) ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld across signal changes not quite right
Mark Murray wrote: I'm not sure how to fix this problem. Unlike our other build tools, perl is not designed to be able to be cross-built: It builds bits of itself and assumes they can be safely executed to build other bits. Perl is hugely fragile; cross-building it is a big PITA. If you have any smart ideas, I'm all ears. I haven't paid any special attention to it yet. (I may have mentioned before that I hate the perl build). No, but it is so noted now :-) -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld across signal changes not quite right
David Scheidt wrote: On Tue, 23 Nov 1999, David O'Brien wrote: Thanks to Marcel's latest Makefile.inc1 changes (1.92), a -current buildworld running on an older -current system now progresses much further - in fact it now completes :-). Actually, I've been seeing just the opposite. Before you could build a -CURRENT kernel and then the world. Now those with worlds from this past summer can't build today's world regardless of which of userland or kernel is built first. The upgrade from -STABLE is also broken because of this. The %expect stuff is blowing up. I haven't yet tried to see if building yacc and bison manually fixes things or not. It will. I will tomorrow, when I have access to the box, assuming my workload doesn't try to kill me first. (I hadn't reported it, because I haven't had time to investigate properly. ) Be prepared to fix gcc and dd too. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Threads and my new job.
Firstly there is some threads discussion going on in -arch so I'm going to really reply to this over there.. This is just redirector mail julian On Mon, 22 Nov 1999, Jason Evans wrote: Walnut Creek has hired me as a full time employee to work primarily on improving and expanding FreeBSD's threads support. This is very exciting to me, and I hope my work will be of benefit the FreeBSD community. [chop] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
"Rodney W. Grimes" [EMAIL PROTECTED] writes: It's not so much that they where ``allowed'' to do it, it is more the matter that they where never directly served with legal papers from USL/Novell to cease all use of Net/2. Nor did they ever enter into any agreement, that I am aware of, with respect to Net/2 code with any party other than UCB. That's half true. No letter ever received asked us to `cease all use of Net/2'. However, as has been publically stated *numerous* times, there does exist an agreement between NetBSD and USL stating that, after certain Net/2 files were removed and certain others were updated to their 4.4-Lite versions, USL would not bother us again. That agreement is different than the agreement I have before me. These agreements basically say that the parties would stop all use of Net/2 based code and replace it with BSD4.4 Lite, [...] That's false. If the FreeBSD agreement is *anything* like the NetBSD one, it covers only specific files, not the entire source tree. You can't make the claim that this is false, you have not seen the document, and you can't. I will assert my statement is true. I can't say anymore about it than that as the agreement itself says that it's contents are not to be disclosed. The agreement evedently does not look like the one that NetBSD signed. One could make claim that Novell/USL seriously failed to do ``due dilegence'', but they where not protecting a trademark, but instead a copyright and they could, if they still owned the code. come along and slap NetBSD/OpenBSD with a pretty healthy law suite. That's also false. Worse, it's FUD. Agreed, given the other statements. Technically if I where to bring a NetBSD repository over to my box and then let anyone other than myself even look at it I would be in violation of the USL/Novell agreement due to the fact that the repository contains Net/2 code. :-(. And that's false, too. You can't know that, you don't know what my agreement says. Unless I missed it some place the ,v files of the NetBSD repository where not purged of the Net/2 code, unless this was done offline in a non-public manner. That I might not know about. Though the legal agreement between NetBSD and USL/Novell may have only required NetBSD to purge certain files, my agreement is very explicit about ALL of Net/2. Please check your facts before spewing about legal matters. My facts on the legal points of this issue are probably at least an order of magnitude more correct than yours. NetBSD wouldn't have even seen something as simple as what it did get from USL had I not spent a month of my time working with Novel legal to have something palatible we (WC and myself) could agree to. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Compiling XFree86 under Current
Here is how i compiled XFree86 today (an additonal file for /usr/ports/x11/XFree86/patches): http://es-i2.fernuni-hagen.de/~jfh/FreeBSD_Documentation/node7.html -- Fritz Heinrichmeyer mailto:[EMAIL PROTECTED] FernUniversitaet Hagen, LG ES, 58084 Hagen (Germany) tel:+49 2331/987-1166 fax:987-355 http://ES-i2.fernuni-hagen.de/~jfh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Buildworld broken in 'usr.bin/kdump' due to ipfilter
Buildworld of today current is broken due to importing of ip_filter's header files with ioctls which in turn broke building 'usr.bin/kdump'. It seems to me that 'mkioctls' script in 'kdump' is "over-automated" - it build the list of the 'ioctl_includes' 'grepping' through the 'include' directory. But often (as in today's sources) new files with ioctls require manually inserting "prerequisite" includes in the same 'mkioctl' script. May be it'll be better if we manually insert BOTH the includes with ioctls and prerequisite files ? N.Dudorov To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Overflow in banner(1)
On Wed, Nov 24, 1999 at 09:58:51AM +0200, John Hay wrote: Well the original line is plain wrong if Brian's patch is being used, because there message is a pointer and the size of a pointer is 4. Yes, yes, yes. Warner and I are *not* that stupid WRT C. We were both commenting on the *original* proposed patch. Geez. Now rather than try to call us stupid, Kris (and only Kris) could say, "well, I've decided to go with a dynamically allocated buffer, so of course I can't use sizeof() any more". -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
On Tue, 23 Nov 1999 23:33:14 -0500 (EST), Brian Fundakowski Feldman [EMAIL PROTECTED] said: #define SNPARGS(buf, len) buf + len, sizeof(buf) len ? sizeof(buf) - len : 0 char action2[32], proto[47], name[18], fragment[17]; /* Print command name */ snprintf(SNPARGS(name, 0), "ipfw: %d", f ? f-fw_number : -1); Despite the fact that the buffer name[] was made to be exactly the largest size Exactly the largest size of what? All I see here is a magic number. Perhaps if name[] had been declared thus: #define INTTYPE_NCHARS(t) ((sizeof(t) * 3 * CHAR_BIT + 7) / 8) char name[(sizeof "ipfw: ") + INTTYPE_NCHARS(int)]; ...but even then, if KNF is followed, this declaration might be so far away from the printf format that when the format is modified, the programmer might forget to modify the declaration as well. snprintf is a good thing. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
In message [EMAIL PROTECTED] Poul-Henning Kamp writes: : In message [EMAIL PROTECTED], Warner Losh writes: : : Not all will agree with this, and it is a change from the past so : there needs to be a sysctl to control this. And given that it is a : radical change from the past, it needs to default to open. : : Now, I can't tell if you wore the security-master hard-hat in this : email or not, and I see some quite divergent australian positions, : so I will sit tight until I see a little bit more of a consensus. It was with my hat on, but lemme explain a little how I got here. Before the recent changes to ps, procfs used to not disclose the command line. When it was modified to be used with a ps that didn't need to be set[gu]id it lost this. I wanted to see it restored for those people that had depended on this, but realized that it would be unpopular (and unnecessary) for many people. As part of the change to restore the behavior, I wanted the sysctl. Now that it is half there, I'd like the other half to complete the picture. The reason that it was a big deal to me was that on the old system if you turned off the setuidness of ps, w, et al you would block disclosure of args/env vars, etc, but still have access to process lists. With the change, there was no way to do this which represented a weakening of the overall system on the whole, despite the strenth added by taking the setgid bit off ps. sef has sent me patches that I've not had a chance to review that appear to implement this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
In message [EMAIL PROTECTED] Peter Wemm writes: : For example, in "workstation" mode, the reasonable default is "open", : because typically there is one user on the box (other than root) and that : person has root access. Excessive hiding info from that user just means : that they'll have to use root more, or will give up the idea of using a mortal : user entirely and run everything as root (a Really Bad idea, think of Windoze : and viruses etc etc). True. : In a dedicated server role, again it might be appropriate to default : it to "open" (dedicated server being something like a squid box), : again there will be a couple of sysadmin type users or people who : have to monitor things. Hiding information gains nothing there : either. I disagree with this, but that is because I've rarely seen a totally dedicated server. A simple fileserver that does nothing else would want to be open in this respect since few people have accounts. : In other roles, including something like a shell server box with presumably : hostile users (you reasonably have to assume this), you want everything you : possibly can to be locked down. Firewall, dialup boxes, dns servers, etc are good candidates to be locked down. : Oh for ACL's, privilige attributes, etc. It would solve this sort of thing : nicely so that you could allow admin users to see what's going on : (including a ps -ax and see what the users are running) without having to : constantly (ab)use root and the dangers of overusing that. sef suggested this be a procfs mount option. I think I like this more than the sysctl option, but don't strong opinion either way (sysctl is more like most of the rest of the system, while a mount option would be harder to change on the fly). Having it be a mount option would make it possible to have a GID that the files are "owned" by that could be 'operator' so that operators can see the args, and possibly other things. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
In message [EMAIL PROTECTED] Alexey Zelkin writes: : What's going on with FreeBSD Auditing Project : (http://www.FreeBSD.org/auditors.html) ? Is it still alive ? : I think this task is task of this project members. Or will be ;-) Went gangbusters for a short while. Everybody was jazzed. Parts of the tree had bugs fixed. Some bug fixes wound up on the floor. Poor central coordination and management of this project was likely a factor. It accomplished some things, but left others undone. It found nothing major that was snuck in while freefall's root had been compromised (which was the impetus behind the project in the first place). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Threads and my new job.
I will admit that I have had odd behaviours with threads in developing Lyris on FreeBSD that I have not seen on Solaris, NT, or Linux. I will see things like what appears to be the thread scheduler stop scheduling threads and just do a busy wait. I have not tracked it down any further for lack of time. -Kip On Wed, 24 Nov 1999, Nick Hilliard wrote: Why do we need to smite the Linux database servers? With threads in their current state they already outperform Linux's native threads by ~50x for things like sending mail. I would assume that the differences in database performance is similar. The threads ( the old nfs issues which have now thankfully been fixed) in their current state led bCandid to write about the Cyclone news router: : Issues the w/FreeBSD kernel and buggy threads have required our development : team to wait until improvements to the OS can be made. We did have a beta : posted on our website for a while but have since removed it. disclaimer: I am not a thread hacker. Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Overflow in banner(1)
I've never done this myself, but I've always been under the impression that sizeof(*buf) would work for dynamically allocated buffers. sizeof() is an operator whose value is determined at compile time. sizeof(*buf) gives the size of what buf points to. This would be `1' if buf were a char*, or `4' if buf were an int* [on the i386]. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Overflow in banner(1)
| sizeof() is an operator whose value is determined at compile time. | sizeof(*buf) gives the size of what buf points to. This would be `1' if | buf were a char*, or `4' if buf were an int* [on the i386]. Ahh, so I've probably seen this concept used only on structures then. -- Dan Moschuk ([EMAIL PROTECTED]) "Cure for global warming: One giant heatsink and dual fans!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
In message [EMAIL PROTECTED], Warner Losh writes: In message [EMAIL PROTECTED] Warner Losh writes: : sef has sent me patches that I've not had a chance to review that : appear to implement this. Actually, these patches do something else. My mistake for reading them before caffeine. So please explain the logic you want implemented once people have stopped haggeling about it, it is rather trivial. I pressume we want the same policy for /proc/*/cmdline as for the sysctl ps(1) uses ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make buildworld blowing up
On Tue, 23 Nov 1999, David O'Brien wrote: Anyone have any ideas whats going on here? Yep. ;-) yacc: e - line 30 of "c-parse.y", syntax error %expect 51 ^ *** Error code 1 The problem is rev 1.92 of src/Makefile.inc1. With that change, the tools needed to build GCC aren't made first. I added a few Bison-like features to Byacc that GCC depended on. The non-tradional "%expect" is one of them. If you manually build and install src/usr.bin/yacc/, a `make world' should then work. Acutally, you should also do the same for src/gnu/usr.bin/bison/ as I think you'll hit another problem later in the build. Excelent, that got me past the first hurdle :) But now its blowing up when compiling /usr/src/gnu/usr.bin/binutils/gdb/ /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:39: readline /readline.h: No such file or directory /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:40: readline /history.h: No such file or directory /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c: In function `line_completion_function': /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:1690: `rl_co mpleter_word_break_characters' undeclared (first use in this function) /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:1690: (Each undeclared identifier is reported only once /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:1690: for ea ch function it appears in.) /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c: In function `readline_line_completion_function': /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:1885: `rl_li ne_buffer' undeclared (first use in this function) /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:1885: `rl_po int' undeclared (first use in this function) /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c: In function `command_line_input': /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:2087: warnin g: assignment makes pointer from integer without a cast /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c: In function `show_commands': /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:3254: syntax error before `*' /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:3261: `histo ry_base' undeclared (first use in this function) /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:3298: invali d type argument of `-' /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c: In function `init_main': /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:3467: `rl_co mpletion_entry_function' undeclared (first use in this function) /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:3470: `rl_re adline_name' undeclared (first use in this function) *** Error code 1 Stop. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
In message [EMAIL PROTECTED] Poul-Henning Kamp writes: : So please explain the logic you want implemented once people have : stopped haggeling about it, it is rather trivial. OK. I'll likely state what I'd like to see as a patch. : I pressume we want the same policy for /proc/*/cmdline as for the : sysctl ps(1) uses ? Yes. I'll firm this up later today and send an exact proposal out so we can kill this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Threads and my new job.
On Wed, Nov 24, 1999 at 01:31:44PM +, Nick Hilliard wrote: Why do we need to smite the Linux database servers? With threads in their current state they already outperform Linux's native threads by ~50x for things like sending mail. I would assume that the differences in database performance is similar. The threads ( the old nfs issues which have now thankfully been fixed) in their current state led bCandid to write about the Cyclone news router: : Issues the w/FreeBSD kernel and buggy threads have required our development : team to wait until improvements to the OS can be made. We did have a beta : posted on our website for a while but have since removed it. disclaimer: I am not a thread hacker. To this I would add that a number of commercial products currently available for FreeBSD depend on the Linux threads implimentation, notably Inktomis' depending on the future of the linux threads stuff, some diplomacy and vendor support may be necesary. What is the current status of the linux threads (Particularly with regard to SMP, which I recall was a problem)? How far from the userland bound original has libc_r moved ? Is the BSDi thread stuff completely seperate from all of this? -- GeoffB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
calcru() warnings...
I still hear reports of sporadic calcru() warnings. If any of you see these, could you try to see if they correlate to the uptime of the machine in question ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
- current diskless is it possible ?
Hi, I have an unconventional setup at home, my PC and an little 386/40 w/o NPU and disk that is routing my net over an ISDN line with i4b to the world. (the router is because there are no free slots anymore in the PC to put the ISDN card in, it is an oldish dual P100 EISA/PCI machine running -current from 3 days ago) So far so good. The problem is, the os on this little diskless router is dated. It is a pre ELF 3.0-current with an I4b from this time too. I have had some problems to get my setup with an new provider (new job) working on an ascent max 1800 and I have decided to update this old router. The router has an wd8013 with an nb8390 boot rom, this seems to make an a.out kernel the way to go (currently) (the linker claims on an symbol _swapdev that he cloudn't find, please someone from the committers can comment this symbol out in sys/i386/i386/symbols.raw nobody needs it anymore) Now I get the Root mount failed: 22 - problem and the machine is asking nicley for a root device. NFS is NOT listed in the list of possible bootdevices, only MFS ?! and something like nfs:139.20.129.5:/usr1/testroot seems to be totally wrong here ^^ I get : no search device: testroot setrootdevname failed. (from my memory, may be a little incorrect) the panic following later is surely related on to this, but it is a page fault. What should I do ? Is an NFS root supported in -current ? How is the syntax to set the rootdevice ? How about /boot/loader and friends - and etherboot ? (the port is outdated, it references etherboot-2.4.5.tar.gz and no one has this old file anymore, current is 2.4.10) Any hints ? Thanks in advance, Holm PS: sorry for my poor english -- FreibergNet Systemhaus GbR Holm Tiffe * Administration, Development Systemhaus für Daten- und Netzwerktechnik phone +49 3731 781279 Unternehmensgruppe Liebscher Partnerfax +49 3731 781377 D-09599 Freiberg * Am St. Niclas Schacht 13http://www.freibergnet.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: calcru() warnings...
Hi, At 8:00 pm +0100 24/11/99, Poul-Henning Kamp wrote: I still hear reports of sporadic calcru() warnings. If any of you see these, could you try to see if they correlate to the uptime of the machine in question ? Nov 23 00:03:35 bludnok /kernel: [boot] Nov 24 09:02:06 bludnok /kernel: calcru: negative time of -4660895 usec for pid 76002 (cc) Ie up just under 9 hours. Building world at the time. This box is running SMP, full details on request. -- Bob Bishop (0118) 977 4017 international code +44 118 [EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: - current diskless is it possible ?
Holm Tiffe writes:
| Is an NFS root supported in -current ?
| How is the syntax to set the rootdevice ?
| How about /boot/loader and friends - and etherboot ?
| (the port is outdated, it references etherboot-2.4.5.tar.gz
| and no one has this old file anymore, current is 2.4.10)
Yes it is possible, but you need to patch sys/i386/i386/autoconf.c. included
in this message. I've only tested in the case of netbooting so I could
broken normal booting.
Then use Etherboot. I also included it an uuencoded update to the
etherboot port for etherboot-2.4.10 which can boot a FreeBSD ELF kenel.
This all works as of -current (yesterday). Sorry it takes so long
for the port to get updated and the Linux guys keep working on Etherboot
(which BTW they has code to boot FreeBSD now and they test it). Then I
have to wait for someone to read the pr's that I send in. They when someone
finally looks at it. It is already obsolete. Same thing with my sdcc
port that needs updating.
I expect Mike will kill me for this, but it works and I don't have a PXE
rom in this machine. I prefer a netboot panic rather then panic'ing my
laptop when testing things.
Doug A.
Index: sys/i386/i386/autoconf.c
===
RCS file: /cvs/freebsd/src/sys/i386/i386/autoconf.c,v
retrieving revision 1.143
diff -c -r1.143 autoconf.c
*** autoconf.c 1999/11/02 19:38:27 1.143
--- autoconf.c 1999/11/24 18:39:47
***
*** 48,53
--- 48,54
#include "opt_bootp.h"
#include "opt_ffs.h"
#include "opt_cd9660.h"
+ #include "opt_nfs.h"
#include "opt_nfsroot.h"
#include "opt_bus.h"
#include "opt_rootdevname.h"
***
*** 213,224
--- 214,231
cold = 0;
}
+ #ifdef BOOTP
+ extern void bootpc_init();
+ #endif
/*
* Do legacy root filesystem discovery.
*/
void
cpu_rootconf()
{
+ #ifdef BOOTP
+ bootpc_init();
+ #endif
#if defined(NFS) defined(NFS_ROOT)
#if !defined(BOOTP_NFSROOT)
if (nfs_diskless_valid)
***
*** 226,232
rootdevnames[0] = "nfs:";
#endif
#if defined(FFS) defined(FFS_ROOT)
! setroot();
#endif
}
SYSINIT(cpu_rootconf, SI_SUB_ROOT_CONF, SI_ORDER_FIRST, cpu_rootconf, NULL)
--- 233,240
rootdevnames[0] = "nfs:";
#endif
#if defined(FFS) defined(FFS_ROOT)
! if (!rootdevnames[0])
! setroot();
#endif
}
SYSINIT(cpu_rootconf, SI_SUB_ROOT_CONF, SI_ORDER_FIRST, cpu_rootconf, NULL)
begin 664 etherboot.tgz
M'XL(`!G].C@"`^U:7/:3!+V5_0KAW7QCG0?0`;4B$@UD;`%.]D.J(48
M@0HA:768%/Y[]LS`HP=9_VFUH%L/$]L(XE6S]'SS'2/6B'9C"3C*,JD@Y\
MT7+,N``0)55DWXBY-7GZ@0L63$-R]0T%4!1%=DX`.-@!\C3S$D`#IS%./'3
M?0]N6,D.#@MP/9V+_Y82#MU_ZR9FJF;%+[YK,[;][^_?QX/'+439-/7_
M8G]-H_:7=471=(O:7].I_65N_Y^.6IR2Y(HDM77[W[E7:4W"/\(!Q^^/._PG
M93Z691[Y3_NG*'_[II:IS_NP!ENN0EA(S3B11'299*(FDS;#@L\!3XK\=
M9HE/TAVO_XIBW/'_=$4S.?]WPO^.,R'Q!)$4VI$X4P(#H%LAJ3=5JN@5*
MM5J5)*$E4:E4DMAQ[3N[.9L/F5'G$[_Q_POS+OG^%\W#.;_JPJ/__=B_Y^Q
M"_`G[2];NJKIAD+M;VH:M_^^[/_8NP`_'O_KAJ;R]9_'_QQ[X?\C[P(\'/];
M=_AO6!:/_W^)^+\8%GPN$K\?^Q=@(?Y;][EOZKJG/\[X?]B8F#HKWX;^AO:
M)O3G]'\R_,?A\.AE/,1_53:VXG^+QG\XW#^[P*=E@''FT%0UD55501NT2
M_OL%U(%,7-'MCLZ*ZQ-,UIVIZRMBJ(8SUCQ%8`K?IAG?I"65;$J*J(L
MJL:6#E4S9$MJ%[%FQC:6)KGJ%JQ+(\UQU799U/+[\"_];P0[YK\JFS?[
M?[HF%_L_!N?_+O`,NF0)S/$'-PH"XF8^@*+U6``+TIJ:*.;YX'/X`-)4BJ3
MD'_E?D(F-;"B0I^U7(R`FY"\*.XS![OF-"($S]@[@0*?9Q%BQK02O*I]!8
MV0#;'8CEC,_S0(BNM'BK?`,[SXZP6#E_:!5@_NBE?4@?GT%BF@4#HQD7!0
M*7I-56NZ##')2`+VYQB.4*'0:@^W4;'KI?NSH+"Q=GI/=\(S;0/NWUV_:@
M7L+2A4YC,+3[HT%[2*_,LBRN2=)RN133()^*43(5G7RKBO!)*U+Y:DX)TE(
M`BHJQ?E8"G`V_2Q-R!4)I*GK?G/'NG-HIT@3[#B)M*D?4XK/1EW:2OJSD8
MCKZ\;WOA^WSPB#W5]?%K#F[X0?^U^O71?CPO"^\OV6O4LB_L;HLVUTD7
MM:,O%[W^-!J][^N*DDO"T*W-[IH-,\:I]AC083C*?)P2(6/\T3AXVJD+@D
M39WD6K@V*/33N/,KBO"Q_[9H-^LE[#F,C48A%%WW^5TL0M:ZJPW8`ZCI=[
M5AR`9U@"F"?)5KX:C5,L193)Z4#29.YJ`N(4Y(5TS4A-*[@2VR[[56?`W
MVOU8HBAM;H'R+$JSNJ]5S'(SL-H997,30)O$+_./#R9_23;DF").H[(X
M%P4!WO3NZ(O=_'OO*_2)ATUAW$4M.Q!LP].%OIIK,FDL:.HN6D$5;EAM
MV'VK0@#'(R0X?KP@BN-K\!?.E(AX!_GL9Z`(@NB';I!/"+S!5HF4:^)B_I8O
MU;_M^K]^I/OX9?Q`_J=N*NSYGZ:_/G/?NS//LN.L[OXS]3UU?Z/;"F6RO9_
M9+[_NQ.\?/D2UDX3.B#^M'22^-!S,U!5D*LUQ:II10Z(4"Z7-Z)WI2HU=27U
M\C;H.5CZ:ZL*[)0JP=.*#'A4%@":)^-T\KJGPB5QT.YUZY\.CXY7QR\^
M'=Z6Z=OGO6;]Z)A]-EJM_@O\_ED#?9.2E*?)O5O8RRB92_X#!+Z!9*3EM%?
M$%X!ZKB9D/X@[BP"493P!^]\N27Z!Q:(/^V6W1UBJ_M33E'Q^_;P\$+N*D]
M')]G..%=\]I+60.X%CCD8$SP)\!EVM3E^1C2")8$9LX5+LK$"6!!%E%R
M31?IA`A[X?]X9_S'=_8\%]C^S]\_W7_\RO_8^]JMR3=YB?R'XK0Q5=_E
M?D5]7:D4W+]%Y$YOV()RJ]W!'4L;N7!:V@1TZXR+PA%6H!W1\%AXJI'E,
M*2[\!26WM#5ZE\,1TX4Z[?.3XGBM\@1UQCLQID?3ID7/"DP98'R0^0L2
MY1D3W-8X.!N][_6=14U-KH##().I?GPSH][MK#C[W^N4HH'?SF;_P/W
MWSSN'C]!_W\U_[N[\_]T;?/\3];48O[G^_^[F_\UMRI_%MU[%P!T_[2;!6`E
M5(O3_M^RN`9K[6U1OOCY[JZ_F23DOKC8;#S5@49XWO@A]EUYZA9\$.V
M(U6,^=HM"WXIM@YBUU?G+VEXB2^-ZJ+S/#TEIV.[8(YQ.2Z:,V/KBG\T/
M_1%.J^UFZ5C^;#1D^87PI/@_G^[W_]5_B=[_]T^?N?[#_SWD'^,?MKVD*
Re: calcru() warnings...
I got a few calcru() warnings on a dual Pentium-III Xeon system. It had been up for around 9 or 10 days or so; I've since rebooted it. Specific configuration available if you need it. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
In the last episode (Nov 23), Lyndon Nerenberg said: After you verify that this change isn't going to break things that assume they can see the *argv list via ps(1). I.e. lightning bolts that do 'kill -MUMBLE `ps -ax|grep foo`'. Which may not be elegant style, but sometimes is the only workable solution. Indeed. There's always a better way, but I've seen countless production systems that do this all the time. In fact, we've only recently done away with all the (sysv) ``ps -ef''s where I work. That won't be affected, because anyone that has kill rights to the process will also see the full processname. Now that I think about it, I can't come up with a case where this is really bad. If you're doing ps'es with intent to kill arbitrary processes (in the name of debugging or whatever), you're probably already root. Or maybe you're a sysadm that's smart enough to use sudo and not run around with root liability in normal life. This was discussed close to death before the changes were committed, and the current behaviour (restricted access) has been agreed by general consensus to be the most appropriate. My reading of the thread was ``I'm going to cache ps args to stop all the delving into user space to do a ps'', ``but what about the -e option'', ``ok, I'll make that inaccessible unless you have permission''. I stopped reading the -e thread because I believe it's a good thing to restrict this. I completely missed that the conversation had moved on to ``hey, who needs ps args anyway'', and I'm sure that given the number of messages posted about the -e restriction, others did too. Making this behaviour tunable would be bad; it adds another option increasing complexity, and with the proposed default in most cases an admin tightening up a system would never know about it in the first place, rendering it useless. I'd strongly recommend leaving things they way they are. This change in behaviour will break production systems, and I'm pretty sure that the breakage will be worked around with a quick ``chmod 4555 /bin/ps''. Is this what we want ? Where I work, we've just done away with all the sysv ``ps -ef'' calls in the system. It took several weeks and a lot of testing. I'd be pretty miffed if the OS shoved this down my throat prematurely as a requirement just be cause I upgraded without knowing of the change. Further, I assert that this change is just wrong ! Why does setproctitle() now require root privileges if nobody can see the results ? This is dumb, as the only uid that we're protecting against is the user that's running setproctitle() ! sendmail/nfs/ppp etc can no longer give normal users information on what's going on via the command args (ok, you can figure out the nfs args). System monitoring scripts will now have to run as root. In fact, why do the processes owned by other users show up at all ? The ``you don't need to see their args'' argument can equally apply to needing to see the entire process you can always kill -0 a process if you need to know if it's running or maybe on second thoughts, we should restrict kill -0 - why should people have this functionality anyway ? I believe the knob is required and should default to the way things were. Well, that's my opinion. I'll calm down now. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org [EMAIL PROTECTED] Don't _EVER_ lose your sense of humour ! [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
Warner Losh wrote: In message [EMAIL PROTECTED] Peter Wemm writes: : : In a dedicated server role, again it might be appropriate to default : it to "open" (dedicated server being something like a squid box), : again there will be a couple of sysadmin type users or people who : have to monitor things. Hiding information gains nothing there : either. I disagree with this, but that is because I've rarely seen a totally dedicated server. A simple fileserver that does nothing else would want to be open in this respect since few people have accounts. : In other roles, including something like a shell server box with presumably : hostile users (you reasonably have to assume this), you want everything you : possibly can to be locked down. Firewall, dialup boxes, dns servers, etc are good candidates to be locked down. Firewall, web, dns, news, etc. servers are good candidates to be open because there should not be any "normal" user accounts on them, only administration accounts. And darned few of those. I think this is what Peter was getting at. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: calcru() warnings...
Poul-Henning Kamp wrote: I still hear reports of sporadic calcru() warnings. If any of you see these, could you try to see if they correlate to the uptime of the machine in question ? Should they start or stop when a machine has been running a while? I see neither (negative calcru notices in dmesg start at boot time and didn't stop until the box had a kernel panic last Saturday evening, after about two weeks uptime). FWIW, the messages started occurring when I switched from a pre-signal to post-signal change kernel and world. -- Niels. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Threads and my new job.
Jason, On Mon, Nov 22, 1999 at 06:52:20PM -0800, Jason Evans wrote: Walnut Creek has hired me as a full time employee to work primarily on improving and expanding FreeBSD's threads support. This is very exciting to me, and I hope my work will be of benefit the FreeBSD community. That's great. Is it part of your remit to maintain http://www.FreeBSD.org/threads/? That URL doesn't exist at the moment, but if we're going to have an active threads project, it probably should. Are you (or anyone else reading this, you don't have to be a committer at the moment) interested in keeping this section up to date? N -- If you want to imagine the future, imagine a tennis shoe stamping on a penguin's face forever. --- with apologies to George Orwell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: calcru() warnings...
On 24-Nov-99 Poul-Henning Kamp wrote: I still hear reports of sporadic calcru() warnings. If any of you see these, could you try to see if they correlate to the uptime of the machine in question ? I have had them for Seti@Home occasionally. The system hadn't been up for more than 24 hours. Its a dual PII-350. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
At 8:03 AM + 11/24/99, Brian Somers wrote: This was discussed close to death before the changes were committed, and the current behaviour (restricted access) has been agreed by general consensus to be the most appropriate. My reading of the thread was ``I'm going to cache ps args to stop all the delving into user space to do a ps'', ``but what about the -e option'', ``ok, I'll make that inaccessible unless you have permission''. I stopped reading the -e thread because I believe it's a good thing to restrict this. I completely missed that the conversation had moved on to ``hey, who needs ps args anyway'', and I'm sure that given the number of messages posted about the -e restriction, others did too. For what it's worth, this is also what happened to me. I tuned out the '-e' thread once I had said my two-bits on the topic (and I was pretty sure the end result would come out OK with me). I did not notice the topic of also removing argv from 'ps'. Removing 'ps -e' ability is fine by me (though I'd prefer that I could see the environment of "my own" processes). I can see how that would improve security, even if it occasionally means a very slight loss in user convenience. I am not at all happy with the idea of removing argv from 'ps' listings. I have scripts which use that information, and it sounds like the only way to fix those scripts would make things WORSE for security. This does not benefit "user convenience" and it does not benefit "security". At the same time, I remember many years ago when another OS that I worked on was trying for security classification. I can see that this behavior *could* be a good idea for situations which want to be really paranoid about security. I would not mind this behavior as a system-wide option, but I'd certainly want the default setting to match current behavior. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Threads and my new job.
[EMAIL PROTECTED] wrote: *) Lacking interfaces, such as pthread_cancel() (mentioned specifically in PR bin/7587) need to be implemented. It's good news for me. I hope to port xmovie -- QuickTime movie Player for Linux to FreeBSD. But I can not compile it under FreeBSD, because it's need pthread_cancel. xmovie http://heroine.linuxbox.com/xmovie.html MIHIRA Yoshiro To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: calcru() warnings...
On Thu, Nov 25, 1999 at 10:38:56AM +1030, Daniel O'Connor [EMAIL PROTECTED] wrote: On 24-Nov-99 Poul-Henning Kamp wrote: I still hear reports of sporadic calcru() warnings. If any of you see these, could you try to see if they correlate to the uptime of the machine in question ? I have had them for Seti@Home occasionally. The system hadn't been up for more than 24 hours. Its a dual PII-350. Same here, running setiathome means that I can find such processes after a day or so: 4 ?? DL -2341043:-35.26 (bufdaemon) The ``calcru'' messages aren't strictly necessary, such things happen without them also. Dual PIII-500, two seti processes. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: calcru() warnings...
Is this SMP ? In message [EMAIL PROTECTED], N writes: Poul-Henning Kamp wrote: I still hear reports of sporadic calcru() warnings. If any of you see these, could you try to see if they correlate to the uptime of the machine in question ? Should they start or stop when a machine has been running a while? I see neither (negative calcru notices in dmesg start at boot time and didn't stop until the box had a kernel panic last Saturday evening, after about two weeks uptime). FWIW, the messages started occurring when I switched from a pre-signal to post-signal change kernel and world. -- Niels. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
