make(1) -DREMOTE?
Hi all, I'm a bit confused about a certain "feature" in make(1). There is a compile-time option that can be enabled: -DREMOTE. This enables (as far as I can tell) some kind of remote job management capability. In three or four years that I've used FreeBSD (as well as other Unix variants), I've never seen this capability demonstrated. So, I'm wondering who uses it, and what purpose it serves. There is nothing in the manpage about this "feature". Thanks, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
pccard issue
I would appreciate it, if someone could give me a hint on this: Our new corporate systems are based on compact pci standard hardware on which FreeBSD works fine. We do have a compact pci pcmcia adapter included. FreeBSD is installed with pccard support and the kernel does recognize the adapter at startup. But when I insert a card into the pcmcia slot during runtime there is no beep nor is there an entry in /var/log/messages. The pccardd is running. Does anyone know what it could be or what I have to do to get any output from pccardd (even if it was just saying "i don't know the card you inserted"). The kernel output at startup: pcic0: VLSI 82C146 at port 0x3e0 iomem 0xd000 on isa0 pcic0: Polling mode pccard0: PC Card bus -- kludge version on pcic0 pccard1: PC Card bus -- kludge version on pcic0 Thanks for your help in advance. Andreas Brodmann --- switch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [PATCH available] TI-RPC and NetBSD's rpc.lockd
I have a second version available. I killed many whitespace diffs, but there are still a lot. http://www.attic.ch/patches/rpc.diff_26122000.tgz WARNING ! THIS BREAKS MAKE WORLD BECAUSE SOME OLD RPC PROGRAMS DO NOT COMPILE AT THE MOMENT. To build do the following: 1.) patch the codebase 2.) cd /usr/src/usr.bin/rpcgen make make install 3.) cd /usr/src/include make clean make make install 4.) cd /usr/src/lib make clean make make install 5.) cd /usr/src/usr.sbin/rpcbind make make install 6.) copy /usr/src/etc/netconfig to /etc 7.) Adjust your rc.conf for rpcbind And if you like to test the NetBSD rpc.lockd: 8.) cd /usr/src/usr.sbin/rpc.lockd make make install I'm off one week and read the emails when I'm back. Martin Martin Blapp, [EMAIL PROTECTED] Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: FreeBSD vs. Linux, Solaris, and NT
I ran into people at NASA who use Python because (beside being a good language) it isn't GPL. Pure paranoia. You don't have to share the code that is written IN Python. Only modifications TO python (if it were GPL) For legal and security reason they cannot share changes to code they make, so anything GPL is unusable. So are programs that run on Linux required to be open source? I need to know. You may only shared link to GPL'ed packages, and the rest is up to you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
On Mon, Dec 25, 2000 at 09:27:49PM -0800, David O'Brien wrote: On Mon, Dec 25, 2000 at 08:29:01PM -0800, Kris Kennaway wrote: Umm, are you actually talking about real incidents here, or just spreading FUD? REAL incidents. Please remember I've been a committer longer you have. This has nothing to do with it, since both of the times you are referring to are well after I became a committer. The last two times a freebsd.org host key has been changed, that I am aware of, a signed message has been sent about it confirming the new key. Uh no. Both of those times that a message was sent out, it wasn't even signed (Internet on 10 May 2000 and Freefall on 16 May 2000). Hop on over the the archives on hub.freebsd.org and get your facts straight. The Internat change didn't even list the new key. And the best we've ever done is in the "HEADS UP: New host key for freefall!" thread started by Peter Wemm on Tue, 16 May 2000 23:26:33. Bollocks. Since you insist, please check the following message IDs which contain PGP signed confirmations of the changed keys. The freefall one especially was just a mixup in timing, not an oversight or gap in policy: Message-Id: [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] So I say again, please stop spreading FUD and making it sound like FreeBSD admins routinely change SSH keys without warning or confirmation. It has happened once in the last year, and the new key was authoritatively confirmed very quickly thereafter. Kris PGP signature
Re: ssh - are you nuts?!?
On Tue, Dec 26, 2000 at 04:22:59AM -0800, David O'Brien wrote: On Tue, Dec 26, 2000 at 04:02:52AM -0800, Kris Kennaway wrote: REAL incidents. Please remember I've been a committer longer you have. This has nothing to do with it, since both of the times you are referring to are well after I became a committer. Both times?? Where in my original email did I ever refer to just two times? When you only gave references to two occasions, and no mention of others. I don't really know how much relevance the admin activities of the ancient past have - the project has changed a lot since those days, and the last two times the host key has publically changed there's been enough discussion of why it needs to be announced that it should have hopefully had an effect, modulo instances of human weakness when people genuinely forget to put the old key back after an upgrade. It isn't FUD, we have handled this poorly in the past five years. So stop calling me a liar, I know what I've freaking experienced in the past. I didn't call you a liar. I said you were exaggerating the incidence of inappropriate SSH key handling. If you feel I've given the wrong impression, fine. Just say that, and I'll clear up that I'm not saying it is intentionally done if that is what people think. But admit to the lack of care of the past. What happens after the next hardware failure? Who ever gets the box running again, will be glad their work is done, and they will not email out a notice. You are complaining to the wrong audience. Talk to [EMAIL PROTECTED], not the FreeBSD user community. Kris P.S. Please stop dropping the mailing list from the CC list of your responses..invest in a simple procmail duplicate message-ID filter if you want to deal with multiple CCs. I can give you one if you like. PGP signature
Re: FreeBSD vs. Linux, Solaris, and NT
[ -hackers - -chat ] On Tue 2000-12-26 (12:44), Marco van de Voort wrote: I ran into people at NASA who use Python because (beside being a good language) it isn't GPL. Pure paranoia. You don't have to share the code that is written IN Python. Only modifications TO python (if it were GPL) For legal and security reason they cannot share changes to code they make, so anything GPL is unusable. So are programs that run on Linux required to be open source? I need to know. You may only shared link to GPL'ed packages, and the rest is up to you. There is plenty of rhetoric on this, but the general view is that system libraries that provide functionality that is available in other non-GPL libraries (that is, libc, and friends) may be linked with, even if the specific library someone links it to is GPL (GNU libc is LGPL anyway, unless that's changed recently, but this theory allows proprietary programs to support free software systems where the libc is GPL [1]. However, deciding to link to other GPL libraries whose interfaces are specific to that library, and for which there are no competing non-GPL libraries (readline, for example), would mean having to make your code GPL. (This is perhaps why "shared linking" is deemed to be allowed by some. However, if this were so, I could take any arbitrary GPL program, wrap most of it up in a library, and shared link to it for most of the work, add some calls into it in my program, to create my own derived program which need not be GPL'd.) The Library General Public License used to be the more tolerant library license, but its use is now slightly discouraged, and it has been renamed the "Lesser" General Public License. The "Why Not LGPL" page suggests to LGPL only libraries that have equivalents in the non-GPL world, as making them GPL doesn't "give free software (sic) any advantage", and to GPL libraries that have no equivalents (giving readline as an example) to make sure proprietary developers cannot use it, unless they decide to use the GPL, or decide to simply write their own version and create the wheel over and over. This is what I perceive to be the general view, and should not be considered legal counsel. ;) 1: I wonder about just providing an object archive to the langauge and make the users link against their GPL libc if I was worried about license problems on a "free software only" system. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: newbus question
No, I don't think so. If I understand what you're talking about, you want to add some extra initialisation for a specific but otherwise standard PCI VGA card, and you want to do this with a device driver which "owns" the card. Exactly. The best way I can think of doing this is as follows: - Your driver should determine whether the VGA adapter is the "primary" adapter. Working this out may be a little tricky. As a first cut, I would consider it as the only card. But yes, I should take this into account. Yes. 8) - In your attach routine (not in the probe routine, since you may not actually win the probe bidding), add extra resources to the device_t which match the "legacy" VGA resources, so that you claim exclusive ownership of these resources. You can do this with bus_set_resource. Can I claim ISA resources while in a PCI probe? Resources are bus dependent like the bus_xxx_resource() functions. Resources are not bus-dependant (there are exceptions, but this is generally true). Even if an ISA driver, or an ISA PnP entry lists these resources, you can still claim them in another driver. In fact, I want to add the linear buffer configuration trick for some S3 cards which have linear frame buffering support but *only* 1.2 VESA. It uses some extra ISA ports just after the standard VGA ones. They're not "ISA ports" so much as just regions in I/O space, and yes, you can easily just claim these. For this, I was thinking of newbusifying vga / vesa and fb and attach my S3 trick to pci and vga. VGA would be a child of isa_vga, as currently, vesa a child of VGA and fb a child of VESA and VGA. Of course in a VESA+VGA configuration there would be two fb... one with vesa support, one without. I would come up with a generic 'vga' driver that has ISA and PCI attachments. You could even ignore ISA-only VGA cards if you were feeling really modern, as they are basically all junk these days. 8) I'm not 100% sure whether VESA should just be an extension to the 'vga' driver, since it just provides a better way of doing some things that the driver would otherwise do. Then 'fb' would be a child of 'vga' (and of any other pixmap device if we ever add others). But this would make the hypothesis that the PCI probe is made before the ISA. You can safely assume that this is true. I'm a bit confused with the current architecture of the VGA/VESA/FB drivers. They call each other and not always in the same direction. Espacially the FB and VGA. Should we have the VGA driver as a backend of the FB one? pci \ vga | \ fb syscons Is how I think it should probably be done, or something similar. Regards, -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
On 25 Dec, Warner Losh wrote: In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : JKH, DG, CORE respond. Core does not respond to mail not directed to it. Posting rules do not allow me to send to more than to groups. Can you recommend a course of action? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
On 25 Dec, Warner Losh wrote: In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : JKH, DG, CORE respond. Core does not respond to mail not directed to it. Posting rules do not allow me to send to more than to groups. Can you recommend a course of action? Short of intensive treatment for hypochondria, no. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
On 25 Dec, Mike Smith wrote: And we, the FreeBSD Project, don't do a thing to help this situation. We change the SSH keys on the freebsd.org machines left and right w/o *ANY* notice to committers that they have been changed. So we've trained our own committers to have sloppy habits that could lead a malicious code added to the FreeBSD CVS source repository. Is this correct? No, in several particulars. "The FreeBSD Project" doesn't change the SSH keys on the FreeBSD.org machines. Notice is given when they are intention ally changed. The FreeBSD Project doesn't "train" committers to have sloppy habits. David has probably been drinking too much; it's Christmas, after all. There were a couple of incidents some time back when freefall's SSH keys were accidentally overwritten due to failure to follow procedure by individual administrators. The lengthy discussions which followed these incidents could not possibly have been construed as "training committers to have sloppy habits". Can anyone confirm this. No. But I'm damn sure that you'd have been fleeing Grover's Mill with the rest of the sheep. JKH, DG, CORE respond. Jordan is in Europe. David is unlikely to pay any attention to this sort of noise. Core does not administer the FreeBSD.org machines, and if you get a response at all, it will probably be "you are talking to the wrong people". Mike, I apprecitate your response. So, I'm paying particular attention to details; I don't want to get this wrong. Your statement says "in several particulars", What does this mean? I think you are meaning to say that "Notice is given when they are intenting all changes", Is this correct? Please, I'm just trying to get it straight what you are saying. As for JKH or DG being out, I would imagine more than one person is away for the holidays. Also, I see your name is listed on the page listing "core" members, so I appreciate this effor on your part. However, this rumor (as I read it now) sounds fantastic, so I'd like to get facts, or at least core's POV (Point Of View). Lastly, you are suggesting that I am talking to the "wrong" people on this. If I am, who are the "right" people? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
On 25 Dec, Peter Wemm wrote: "David O'Brien" wrote: And the best we've ever done is in the "HEADS UP: New host key for freefall!" thread started by Peter Wemm on Tue, 16 May 2000 23:26:33. ... which the thread and FUD was a total load of shit, because the original keys were never announced or signed or anything. The new keys were no more or less trustworthy than the old ones. Wait, I'm trying to get this straight. If I read what you are saying, and please correct me if I'm wrong, you are saying "the original keys were never .". Which original keys are you talking about? Are you saying that the original SSH Public Keys for the servers were always sent in the clear, without PGP signature or anything? Is this correct? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
On 26 Dec, Kris Kennaway wrote: On Mon, Dec 25, 2000 at 09:27:49PM -0800, David O'Brien wrote: On Mon, Dec 25, 2000 at 08:29:01PM -0800, Kris Kennaway wrote: Umm, are you actually talking about real incidents here, or just spreading FUD? REAL incidents. Please remember I've been a committer longer you have. .[TRIMMED]... Since you insist, please check the following message IDs which contain PGP signed confirmations of the changed keys. The freefall one especially was just a mixup in timing, not an oversight or gap in policy: Message-Id: [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] So I say again, please stop spreading FUD and making it sound like FreeBSD admins routinely change SSH keys without warning or confirmation. It has happened once in the last year, and the new key was authoritatively confirmed very quickly thereafter. Wait. If what David says is correct and what Kris says is correct, then I guess the next question is: What is the policy when a "commiter" reports this type of schenario? My guess is that such a situation would not be ignored, and as such, any commiter encountering such a situation should report the incident immediately. This should be the policy for if what I've read and heard about SSH is true, then what David is saying merits a policy and investigation by the SO. If it is FUD as you claim, then the call should be made by the SO. This would seem to be prudent policy. Lastly, I'm not here to question policy, just report on it. respectfully, Jessem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
If it is FUD as you claim, then the call should be made by the SO. This would seem to be prudent policy. Jesse, Kris *is* the Security Officer. Now, please let this thread die. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
On 26 Dec, Kris Kennaway wrote: On Tue, Dec 26, 2000 at 04:22:59AM -0800, David O'Brien wrote: If you feel I've given the wrong impression, fine. Just say that, and I'll clear up that I'm not saying it is intentionally done if that is what people think. But admit to the lack of care of the past. What happens after the next hardware failure? Who ever gets the box running again, will be glad their work is done, and they will not email out a notice. You are complaining to the wrong audience. Talk to [EMAIL PROTECTED], not the FreeBSD user community. I disagree with your statement. From what I'm reading, it seems that "the enforcement of policy" has been lacking of that current policies need revamping. If the former is the case, then the new SO has his work cut out for him. If the later is the case, then his complaint merits attention, and immediate action. Mind you I'm not suggesting this change. However, one of my counter-proposals to SSH (to be given at the talk) is the "enforcement of policy". And to wit, if said policy is weak, then the underlying structure (or framework) should be expected of similar condition. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
Which original keys are you talking about? SSH public server keys. (Sometimes called "server identities"). Are you saying that the original SSH Public Keys for the servers were always sent in the clear, without PGP signature or anything? David was saying that, but he's wrong. There was a time that we were very lax about confirming the server public keys. The last round of changes have all been confirmed by digital signature by well-known server administrators. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
On Tue, Dec 26, 2000 at 08:04:20AM -0800, [EMAIL PROTECTED] wrote: You are complaining to the wrong audience. Talk to [EMAIL PROTECTED], not the FreeBSD user community. I disagree with your statement. From what I'm reading, it seems that "the enforcement of policy" has been lacking of that current policies need revamping. If the former is the case, then the new SO has his work cut out for him. It is impossible for you[or anyone not on committers/developers] to: 1) know the policies 2) know the specifics of the incidents that are being discussed 3) have read any of the mail regarding the incidents The FreeBSD admins do an excellent job and I've never felt insecure because of their policies. Please end this thread now, it doesn't belong on the public mailing lists. If the later is the case, then his complaint merits attention, and immediate action. Mind you I'm not suggesting this change. However, one of my counter-proposals to SSH (to be given at the talk) is the "enforcement of policy". And to wit, if said policy is weak, then the underlying structure (or framework) should be expected of similar condition. I can't find a point in the above paragraph besides "bad stuff is bad." -- Bill Fumerola - security yahoo / Yahoo! inc. - [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
Alex Belits wrote: On Sun, 24 Dec 2000, Wes Peters wrote: That depends on the type of "aggregation". If you produce a single-purpose device, like an "internet radio", the entire device has a single purpose, therefore every part of the device is "derived from" every other part. WTF are you talking about? Derived work is the result of modification of the original, not just something dependent on its functionality. From the "10 big myths about copyright explained" page: http://www.templetons.com/brad/copymyths.html 6) "If I make up my own stories, but base them on another work, my new work belongs to me." False. Copyright law is quite explicit that the making of what are called "derivative works" -- works based or derived from another copyrighted work -- is the exclusive province of the owner of the original work. This is true even though the making of these new works is a highly creative process. If you write a story using settings or characters from somebody else's work, you need that author's permission. How this exactly applies to software has never been tested in court, and is therefore in question. You appear to not understand how the US legal system (and any other derived from English common law) works, and the power of "precedent." Linus has specifically disclaimed such types of aggregation in public state- ments, but this sentiment is NOT reflected in the actual text of the license. -- "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-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
Rik van Riel wrote: On Mon, 18 Dec 2000, Murray Stokely wrote: I want to create a comprehensive body of knowledge that can then be used to make fliers to hand out to Linux weenies at ^ trade shows, published on bsdi.com and/or freebsd.org, etc.. Haha ;) With an attitude like that, you'd be hard-pressed to convert people to *BSD, which is a shame IMHO, because both *BSD and Linux have lots of good things to offer and (still) have some different strong and weak points... Ah, come one, everyone HERE knows that "Linux weenies" is a subset of "Linux users." A vocal, undereducated subset, but still a subset. I know of at least one "FreeBSD weenie" too, weenies are not exclusive to Linux. -- "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-hackers" in the body of the message
Re: ssh - are you nuts?!?
[EMAIL PROTECTED] wrote: This is one of the stupidest trolls I've ever found, and is completely inappropriate for freebsd-security. Try over on -chat. I'm not sure of this. SSH is about Secure SHell. It's this where I might get technical answers about security? This mailing list is for specific questions and answers about FreeBSD security. If you want to discuss ssh, find a mailing list or newsgroup about ssh. -- "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-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
. Apparently you never did reverse engineering. When I did such things I got the code de-compiled (manually) back to the C language. It's a bit boring but not too much work even for the RISC machines (and mauch easier for IA-32 than for RISC). And it's legal to do outside US for the purpose of learning the interfaces. (I believe that it should be made legal in US too). -SB But its not legal to distribute, so its moot. The issue with supplying source is allowing your software technology investment to be used freely on competitor's hardware. The purpose of developing software technology is to have an advantage over your competitors in selling your product. You develop software to make your hardware more attractive for sale. If everyone has the same software (ie most linux and freebsd ethernet cards and wan cards) then there is no incentive to spend dollars on software development. DB DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mtrr and stepping=2 K7's
Are there any known issues with MTRR on early K7's? Using XFree86 4.0.x on an early 550 Mhz K7 (equipped with 256Megs of sdram) causes this machine to lock up, unless I comment out the K7 mtrr enabling stuff in i686_mem.c. This happens with any VGA card that I drop in the box, (PCI bus voodoo4, a Rage IIc ATI card, and the Matrox G400). Thanks, Joe Orthoefer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [PATCH available] TI-RPC and NetBSD's rpc.lockd
On Tue, Dec 26, 2000 at 02:20:46AM +0100, Martin Blapp wrote: [snip] Issues with the code: 1.) NETBSD sets in svc_tcp.c some LOCAL_CREDS which we don't have in our src/sys/kern/uipc_usrreq.c. They have a FLAG which - if set - automatically sends the credentials on AF_UNIX sockets connections if we do a recvmsg(). We have to implement this to have rpcbind properly working. AF_UNIX socket operations are broken at the moment, but with compability-mode 'rpcbind -Li' rpcbind works. We have something analogous ... look for SCM_CREDS. It's a shame these aren't the same on both (Net|Free)BSD. To narrow it down for you, here are the relevant files in -CURRENT: src/sys/kern/uipc_usrreq.c src/lib/libc/rpc/clnt_unix.c src/lib/libc/rpc/svc_unix.c keyserv and rpc.yppasswd are example applications that use this feature. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
On Tue, Dec 26, 2000 at 04:43:37AM -0800, Kris Kennaway wrote: P.S. Please stop dropping the mailing list from the CC list of your responses.. Thank you for taking away my right to take a discussion private, and posting my *private* response to a public mailing list. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make(1) -DREMOTE?
and I guess you tried to compile it with this define and it didn't work! probably someone was working on it (or is he still working on it) to implement remote make jobs, aka dmake. so this is mostly "work in progress" or "unfinished". regards, mouss At 04:01 26/12/00 -0500, Will Andrews wrote: Hi all, I'm a bit confused about a certain "feature" in make(1). There is a compile-time option that can be enabled: -DREMOTE. This enables (as far as I can tell) some kind of remote job management capability. In three or four years that I've used FreeBSD (as well as other Unix variants), I've never seen this capability demonstrated. So, I'm wondering who uses it, and what purpose it serves. There is nothing in the manpage about this "feature". Thanks, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
On Tue, Dec 26, 2000 at 06:09:26PM +0200, Mark Murray wrote: Are you saying that the original SSH Public Keys for the servers were always sent in the clear, without PGP signature or anything? David was saying that, but he's wrong. How I enjoy when someone tries to put words in my mouth. No, I did not say "the original SSH Public Keys for the servers were always sent in the clear, without PGP signature", I said *announcement* of their change was. And as much as I'd like to back out of this discussion, I don't like being called a liar. Both Peter's *original* (see that word above) email sending out the fingerprint of the new key, WAS in the clear without PGP signature. As was John Hays announcement announcing the key change on Internet. Message-Id: [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard issue
Have you checked for IRQ/iomem conflicts? I had those, and corrected them with: # in /etc/rc.conf card_enable=YES pccard_mem=0xd8000 pccard_conf=/etc/pccard.conf # in /boot/loader.conf machdep.pccard.pcic_irq=5 - Original Message - From: "Andreas Brodmann" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 26, 2000 3:08 AM Subject: pccard issue I would appreciate it, if someone could give me a hint on this: Our new corporate systems are based on compact pci standard hardware on which FreeBSD works fine. We do have a compact pci pcmcia adapter included. FreeBSD is installed with pccard support and the kernel does recognize the adapter at startup. But when I insert a card into the pcmcia slot during runtime there is no beep nor is there an entry in /var/log/messages. The pccardd is running. Does anyone know what it could be or what I have to do to get any output from pccardd (even if it was just saying "i don't know the card you inserted"). The kernel output at startup: pcic0: VLSI 82C146 at port 0x3e0 iomem 0xd000 on isa0 pcic0: Polling mode pccard0: PC Card bus -- kludge version on pcic0 pccard1: PC Card bus -- kludge version on pcic0 Thanks for your help in advance. Andreas Brodmann --- switch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
-STABLE+vinum+smp+softupdates+CVSup(local CVS repo)==corruption?
I have run across a problem since updating to -STABLE a week or so ago... my CVS vinum partition would go corrupt after a few updates. I have been running with no softupdates on my system for a day now and no problems. Has anyone else seen this? -- David Cross | email: [EMAIL PROTECTED] Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: -STABLE+vinum+smp+softupdates+CVSup(local CVS repo)==corruption?
On Tuesday, 26 December 2000 at 17:30:09 -0500, David E. Cross wrote: I have run across a problem since updating to -STABLE a week or so ago... my CVS vinum partition would go corrupt after a few updates. I have been running with no softupdates on my system for a day now and no problems. Has anyone else seen this? I haven't heard of any such problem, but with the details you give, it's difficult to tell. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [PATCH available] TI-RPC and NetBSD's rpc.lockd
On Tue, Dec 26, 2000 at 02:20:46AM +0100, Martin Blapp wrote: [snip] Issues with the code: 1.) NETBSD sets in svc_tcp.c some LOCAL_CREDS which we don't have in our src/sys/kern/uipc_usrreq.c. They have a FLAG which - if set - automatically sends the credentials on AF_UNIX sockets connections if we do a recvmsg(). We have to implement this to have rpcbind properly working. AF_UNIX socket operations are broken at the moment, but with compability-mode 'rpcbind -Li' rpcbind works. We have something analogous ... look for SCM_CREDS. It's a shame these aren't the same on both (Net|Free)BSD. I'm responsible for implementing this feature. When I sat down to try and make secure RPC work, I was unaware of the existence of the LOCAL_CREDS feature that had been implemented in BSD/OS at about the same time. What I wanted was a way to provide credentials for each *message* rather than for each socket, since RPC is more or less message-based. I was also concerned with avoding problems that might arise if a client process fork()ed while holding open a socket to which credential info had been assigned. You obviously don't want the parent and the child process to return the same credential info. Using the SCM_CREDS 'hack' was a) expedient, as it only involved a minor change to the kernel and b) it seemed to agree with the way RPC worked, i.e. each RPC needs the credential info for authentication. The reason you need the LOCAL_CREDS/SCM_CREDS stuff at all is that keyserv needs to know the identity of the user that's talking to it. It must not allow access to a user's diffie-helman key pair to anyone other than the user to whom it belongs (and, potentially, the superuser). The problem is the original sockets API did not provide any way for this authentication do be done. Many alternatives were discussed and rejected because they were too complex or just plain didn't work. The notion of using credentials was new in TI-RPC because STREAMS/TLI offers a way to do it. In SunOS 4, there was instead a terrible kludge based on the ugly and bletcherous keyenvoy program. I made keyenvoy work, but it struck me that it had a potentially serious weakness: it depended on the "only root can bind to port numbers less than 1024" property of UNIX TCP/IP networking, and it distinguished local connections from remote ones by comparing the origin IP address with 127.0.0.1. (Can you say IP spoofing? I knew you could.) Anyway, imagine my surprise when, after going to all the trouble of thinking up the SCM_CREDS hack, making it work, and then patting myself on the back for being clever, I opened up my brand new copy of _UNIX Network Programming, 2nd Edition, Vol I_ and found that some fool at BSDi had come up with the idea first. :) NetBSD uses the BSD/OS approach rather than the FreeBSD approach. In theory, you could have both. I still say the per-message credential mechanism works better with RPC, but I'm just a crotchety old fart anyway. Relatively speaking. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
[EMAIL PROTECTED] wrote: On 25 Dec, David O'Brien wrote: On Fri, Dec 22, 2000 at 11:28:07PM -0800, Kris Kennaway wrote: Incorrect..the problems with SSH come down to flaws in the human operator who ignore the warnings SSH gives them, and tell it explicitly to do insecure things like connect to a server which is suddenly not the one you're used to connecting to. And we, the FreeBSD Project, don't do a thing to help this situation. We change the SSH keys on the freebsd.org machines left and right w/o *ANY* notice to committers that they have been changed. So we've trained our own committers to have sloppy habits that could lead a malicious code added to the FreeBSD CVS source repository. Is this correct? Can anyone confirm this. A message by Wes Peters suggests it to be so. No message from me suggested anything about ssh key handling by the FreeBSD project. Don't start quoting me out of context. -- "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-hackers" in the body of the message
Re: make(1) -DREMOTE?
Will Andrews [EMAIL PROTECTED] writes: So, I'm wondering who uses it, and what purpose it serves. There is nothing in the manpage about this "feature". I believe these are left-overs from the customs support that pmake (aka 4.4BSD make) used to have a long time ago. You might want to look at the `devel/pmake' port. /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [PATCH available] TI-RPC and NetBSD's rpc.lockd
On Tue, Dec 26, 2000 at 03:33:53PM -0800, Bill Paul wrote: I'm responsible for implementing this feature. Thanks for that! Using the SCM_CREDS 'hack' was a) expedient, as it only involved a minor change to the kernel and b) it seemed to agree with the way RPC worked, i.e. each RPC needs the credential info for authentication. Anyway, imagine my surprise when, after going to all the trouble of thinking up the SCM_CREDS hack, making it work, and then patting myself on the back for being clever, I opened up my brand new copy of _UNIX Network Programming, 2nd Edition, Vol I_ and found that some fool at BSDi had come up with the idea first. :) NetBSD uses the BSD/OS approach rather than the FreeBSD approach. In theory, you could have both. I still say the per-message credential mechanism works better with RPC, but I'm just a crotchety old fart anyway. With regards to `the per-message credential mechanism works better with RPC': in fact, the way Solaris handles this (now?) is a per-message credential mechanism. Local RPC is implemented on top of doors (see UNPv2 chapter 15) rather than sockets. A doors procedure can use door_cred() to get client creditials each time it is invoked (i.e. per message). Switching gears back to the BSD/OS approach you mentioned, UNPv1 says, On a datagram socket, the credentials accompany every datagram. On a stream socket, the credentials are sent only once, the first time data is sent. So as long as one is using a SOCK_DGRAM socket, the BSD/OS-NetBSD approach should be analogous to what we have currently in FreeBSD? -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [PATCH available] TI-RPC and NetBSD's rpc.lockd
[chop] Switching gears back to the BSD/OS approach you mentioned, UNPv1 says, On a datagram socket, the credentials accompany every datagram. On a stream socket, the credentials are sent only once, the first time data is sent. So as long as one is using a SOCK_DGRAM socket, the BSD/OS-NetBSD approach should be analogous to what we have currently in FreeBSD? What if the client creates a TCP socket, the credentials are sent, then the process fork()s. Yeah, I know: why in the hell would you do that? Who knows, but you have to account for all cases. Even though you may have a TCP stream socket, you're still sending discrete requests and replies over it. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
On Tue, Dec 26, 2000 at 11:20:34AM -0800, David O'Brien wrote: On Tue, Dec 26, 2000 at 04:43:37AM -0800, Kris Kennaway wrote: P.S. Please stop dropping the mailing list from the CC list of your responses.. Thank you for taking away my right to take a discussion private, and posting my *private* response to a public mailing list. Oops, here's what happened: the previous mail you sent to me in this thread was sent twice separately; one sent to me only, not the list, and another sent only to the list - perhaps you used a BCC. The message in my email inbox had the mailing list removed from it, and I had to add it back by hand - I assumed you had done the same thing here, but it turns out you only did send me a private reply. I guess this bears out my point above about why this was a bad thing to do. Kris P.S. I don't think there's anything else which needs to be said in this thread, so I'll be decoupling from it now.. PGP signature
waiting for new files in a directory
FreshPorts2 will have a new processing strategy for incoming messages. Each message will be in a separate file in a predetermined directory. As each file arrives, it is processed by a perl script. I want only one instance of that perl script running at a given time. This is primarily for serialization and to ensure the system doesn't get bogged down running perl scripts if many messages arrive in a short period of time. My idea is to have a daemon, or something resembling one, sitting on the box watching the directory. When a new file appears, it starts a perl script. This perl script is beyound the scope of my question, but it processes all the files in the directory. When finished, it looks for any more files and repeats as necessary. If no more files, it exits. If a file arrives, the daemon checks to see if the perl script is already running. If so, it doesn't start another one. Any ideas on how to do this? Any suggestions on the process? -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
