Re: source IP address
"CRL" == Chad R Larson [EMAIL PROTECTED] writes: Telnet does. It would be really used if ssh did also. CRL Really? I can't find an option that allows that. The closest I see -s src_addr Set the source IP address for the telnet connection to src_addr, which can be an IP address or a host name. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: source IP address
As I recall, Vivek Khera wrote: "CRL" == Chad R Larson [EMAIL PROTECTED] writes: Telnet does. It would be really used if ssh did also. CRL Really? I can't find an option that allows that. -s src_addr Set the source IP address for the telnet connection to src_addr, which can be an IP address or a host name. Hmmm... Later version of telnet(1), I guess. Mine doesn't have a "-s" option. It =does= have a "-S" option, which allows you to request a type of service. -crl -- Chad R. Larson (CRL15) 602-953-1392 Brother, can you paradigm? [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] DCF, Inc. - 14623 North 49th Place, Scottsdale, Arizona 85254-2207 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Two FreeBSD Server (and) CVSUP Refure File
At 03:22 PM 11/14/00 +, G D McKee wrote: Hi How can I get a second FreeBSD server to masquerade through another one hooked up to the internet using ppp without enabling nat in ppp.conf file. Everything else from other PC's goes through squid or socks5 proxies. Can I do anything with IPFW or is nat the only option. I don't want to enable nat for security. G D McKee and... At 03:26 PM 11/14/00 +, G D McKee wrote: Hi It is not clear where this file has to be placed in the file system. Can someone please advise? It mentions /usr/sup, but this dir doesn't exist? At present I have put it in /usr/local/etc/cvsup. G D McKee These questions have nothing to do with the -stable mailing list and and are more approriately belong on -questions. Checking the archive will find that they have been answered several times. Pardon the gripe, but I feel this list is really starting to turn into an "any question goes" list, which is not supposed to be the case. The list charter for reference: FREEBSD-STABLE Discussions about the use of FreeBSD-stable This is the mailing list for users of freebsd-stable. It includes warnings about new features coming out in -stable that will affect the users, and instructions on steps that must be taken to remain -stable. Anyone running ``stable'' should subscribe to this list. This is a technical mailing list for which strictly technical content is expected. It's great that we have a lot of new users here, but feel that the wrong impression about this has been given. As a newcomer you have been targeted as a matter of example and expedience. I'd *strongly* suggest reading the handbook, FAQ, and obtaining a copy of "The Complete FreeBSD" and also subscribe to -cvs-all and -ports if you wish to track stable. Otherwise stick with releases. cheers! PS - Either lose the Outlook mailer or send mail to the lists as plain text. Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ports collection
At 03:35 PM 11/14/00 -0500, Evan S wrote: I cvs'uppd my ports collection like the handbook and UPDATING file said to, will that be enough so after I make installworld and merge master my ports won't have to be recompiled? Thanks, Evan Sarmiento ([EMAIL PROTECTED]) http://sekt7.org/es While I am busy griping here is another example. This question more appropriate to -ports, but at least marginally concerns -stable. I'm not saying this doesn't belong here, but there have far too many ports specific questions on this list. Myself and others have pointed this out. In many cases the questions were answered very recently on -ports. If you use ports you should be reading -ports. When in doubt re-compile them. If you track -cvs-all (like you are *supposed* to), then re-compile them only when you changes to libraries. The pending version bump is by far the best example, but re-doing the ports you install is a good blanket rule when a commit has "lib" in it. Call it the "when in doubt" rule. ;) As for how, check the archives for -stable and -ports. ;) Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
updating system and warning with ports
Hello, I updated my system an now I get a warning, when I use lsof: ..compiled for 4.1 .. this is 4.2 I know this happens only at system near ports. How I get a list of ports which produce this warning so the users don't report me this warning after the update? Thanks. -- Noch einen schönen Tag Noel Köthe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version (consensus?)
At 03:26 PM 11/13/00 -0800, David O'Brien wrote: On Mon, Nov 13, 2000 at 03:06:41PM -0800, Satoshi - Ports Wraith - Asami wrote: * I'm going to go ahead and bump -current's libc today in preparation of * doing in -stable if it comes down to it. I know Garret has been waiting * to make some changes that would need a bump anyway. So it won't be * wasted. Can you commit the change RSN? I need a new snap with the updated version numbers before I can even start rebuilding the packages. We are in a race against time now. What's the holdup? Root canal crown prep and make world time. :-) Sorry to hear. sudder Is the bump going to happen before 4.2 or not? I *do* realize what PITA this is. Though for some it is an opportunity, as they can make changes to -current that would require a version bump. Of course if the those changes can be MFC'd then we are in the same boat down the line at some point and -current must be then bumped before -stable can again be bumped. And another compat distribution. 8-/ Main concern is the looming release date 6 days. Would rather see this done right and delay the release past the 20th. Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version
* From: "David O'Brien" [EMAIL PROTECTED] * Not sure if you saw this message. The more I think about it, I'm not * sure bumping the shared libc version will accomplish anything other than * require a compat4x distribution for 4.2-RELEASE. For the 4.0R upgrade * kit you'd just have to include a libc.so.5, and that would mismatch the * kernel as bad as the libc.so.4 that is currently included. Hmm. That's a good point. So you mean there is no way to build a libc that works for 4.2 that will also work with a 4.0 kernel? (I don't think just changing the libc source on a 4.0 machine will accomplish that. Besides, that sounds even more dangerous, to build something with mixed sources.) * How did you get the included libc.so.4? If you just took a -stable one * that could easily be the problem. The most correct way would be to take * a 4.0-R machine w/src (or at least source and a chrooted build * environment) and only update the libc sources and build libc.so.4 that * way. I don't know enough about the libc to make a decision here, so I will respect whatever you experts decide. However, incompatible is incompatible and it seems to me that we should still bump the version of libc just to make sure people won't get into a similar situation by copying supposedly compatible shared library. (If libc was at so.5 in the upgrade kit it at least wouldn't have killed existing binaries.) By the way, if the conclusion is that we can't provide an upgrade kit that will work for 4.0R (regardless of whether we bump libc or not), I'll just replace that package with something that prints "sorry, we can't support that system anymore, please upgrade". Satoshi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version (consensus?)
On Tue, Nov 14, 2000 at 04:03:19PM -0600, Jeffrey J. Mountin wrote: Is the bump going to happen before 4.2 or not? I don't know. I'd like to hear Satoshi's response to my last email on the topic. The typical test [in this case] would be does a 4.0R shared binary still run fine on a 4.2-R system. No one has brought this up as the case. And for the example given, I don't know how bumping libc's shared version number will solve the problem. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Bridging code in 4.2RC1 still not fixed
On Tue, 14 Nov 2000, Thomas T. Veldhouse wrote: It has been mentioned in the past many many times - and promptly forgotton just as many times. Forgive the harsh sounding critcism - just trying to get attention called to this issue. It is not at all hard to reproduce - but it does not log anything to the system logs when this sort of crash happens. The fact that nobody has looked at this over the course of the last year really surprises me. Tom Veldhouse [EMAIL PROTECTED] You know what's unfortunate? What's unfortunate is that this entire thread has failed to provide any single piece of VALID debugging information, despite my (and I'm sure others') efforts in obtaining that. Even if "the problem" isn't that hard to reproduce, maybe there are more than one problem. Maybe there is only one, but its side-effects are apparent at several different places. Unless someone experiencing the problems provides valid debugging information, how exactly do you expect anybody to fix it? Simply saying "yeah, there's a problem, it's related to X, so fix it" just doesn't cut it, if you're expecting people to prioritize it. Furthermore, I've noticed that Marko's report doesn't include the debugging information which I feel I made very clear is required to even glance at the problem. Regards, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.2 BETA build kernel failure on NCR 53C810
The problem was due to how I left several options from my kernel. Adding them fixed the kernel compile problem. Thanks, Hoang --- David O'Brien [EMAIL PROTECTED] wrote: On Mon, Nov 13, 2000 at 07:19:33PM -0800, Hoang Tran wrote: I just added a NCR 53C810 and rebuild the kernel it's failing on linking: What does your kernel config file look like? If it isn't GENERIC, try the `sym' driver. It is a better driver at this point than the `ncr' one and supports the same cards. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX __ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Mouse troubles in X and console (warning: contains graphic pleas forhelp :))
I have noticed the same thing in 4.1-RELEASE. I dont have a clue why it does that. When I killed moused and ran it again, everything worked fine. I never saw the raw input from the mouse on the terminal. I know I'm not much help, but perhaps someone else knows whats going on? Caleb Land wrote: Hello, About three days ago I was using X, and my mouse froze in it's tracks. I know that X didn't freeze because I could still operate it with the keyboard. So, after I saved my work, I used CTRL-ALT-BACKSPACE to halt X. Then I killed ``moused'' and ran it again. Then when I moved my mouse in the console tons of characters (a lot of dollar signs ($)) were being input on standard input (as if I were typing them, I received a lot of "command not found" errors). If I start X when it is acting like this my mouse goes crazy when I move it. It clicks everywhere, and jumps from one side of the screen to the other. When I reboot the machine everything is normal again until I start X and use it for a little while. Through much rebooting, I've determined that moving a window from one virtual desktop to another will get it to freeze more quickly, though other activity causes it too. I tried installing X from cvs, but that didn't fix anything. I tried cvsup'ing by adding: date=2000.11.01.01.01.01 and making a new kernel and world, but that didn't help (it worked until a couple of days ago, so I thought that a recent installworld might have caused it, but it still didn't work with the old sources) I've tried not running moused on boot, and just using the mouse in X with the type set to "PS/2" and the device set to "/dev/psm0" Here is some information about my system: * Dual PIII 500 on a Supermicro P6DGE * 256 MB of Memory (I added 128 last week, and that is when I recompiled my kernel because for some reason I have 128 MB of memory hardcoded in my kernel config.) * Intellimouse Explorer (the one with 5 buttons and a wheel) hooked up to the PS/2 port because the USB never worked with SMP for some reason. * First X 4.0.1 from the ports collection, then from CVS, same problem The mouse works fine in Windows, and worked fine since March 2000 when I installed FreeBSD 4.0 until now. If you need more specific information tell me how to get it and I will (maybe some sort of kernel log or something). I'm stumped. -- Sincerely, Caleb Land ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message -- Ben Pfountz Computer Science Undergraduate Virginia Tech [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Mouse troubles in X and console (warning: contains graphic pleas forhelp :))
This has been answered a view times over on this list when XFree-4.0.1 first came out. The fix/workaround is to tweak your XF86Config file. For me, changing Option "Protocol" from "Auto" to "Mousesystems" worked. Ben Pfountz wrote: I have noticed the same thing in 4.1-RELEASE. I dont have a clue why it does that. When I killed moused and ran it again, everything worked fine. I never saw the raw input from the mouse on the terminal. I know I'm not much help, but perhaps someone else knows whats going on? Caleb Land wrote: Hello, About three days ago I was using X, and my mouse froze in it's tracks. I know that X didn't freeze because I could still operate it with the keyboard. So, after I saved my work, I used CTRL-ALT-BACKSPACE to halt X. Then I killed ``moused'' and ran it again. Then when I moved my mouse in the console tons of characters (a lot of dollar signs ($)) were being input on standard input (as if I were typing them, I received a lot of "command not found" errors). If I start X when it is acting like this my mouse goes crazy when I move it. It clicks everywhere, and jumps from one side of the screen to the other. When I reboot the machine everything is normal again until I start X and use it for a little while. Through much rebooting, I've determined that moving a window from one virtual desktop to another will get it to freeze more quickly, though other activity causes it too. I tried installing X from cvs, but that didn't fix anything. I tried cvsup'ing by adding: date=2000.11.01.01.01.01 and making a new kernel and world, but that didn't help (it worked until a couple of days ago, so I thought that a recent installworld might have caused it, but it still didn't work with the old sources) I've tried not running moused on boot, and just using the mouse in X with the type set to "PS/2" and the device set to "/dev/psm0" Here is some information about my system: * Dual PIII 500 on a Supermicro P6DGE * 256 MB of Memory (I added 128 last week, and that is when I recompiled my kernel because for some reason I have 128 MB of memory hardcoded in my kernel config.) * Intellimouse Explorer (the one with 5 buttons and a wheel) hooked up to the PS/2 port because the USB never worked with SMP for some reason. * First X 4.0.1 from the ports collection, then from CVS, same problem The mouse works fine in Windows, and worked fine since March 2000 when I installed FreeBSD 4.0 until now. If you need more specific information tell me how to get it and I will (maybe some sort of kernel log or something). I'm stumped. -- Sincerely, Caleb Land ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message -- Ben Pfountz Computer Science Undergraduate Virginia Tech [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/University of Southern California S/MIME Cryptographic Signature
Re: libc shlib version
On Tue, Nov 14, 2000 at 02:15:49PM -0800, Satoshi - Ports Wraith - Asami wrote:
Hmm. That's a good point. So you mean there is no way to build a
libc that works for 4.2 that will also work with a 4.0 kernel?
Yes.
(I don't think just changing the libc source on a 4.0 machine will
accomplish that. Besides, that sounds even more dangerous, to build
something with mixed sources.)
IF 4.2-R libc sources would compile on a 4.0-R system the resulting
libc.so.4 will work much better than using a stock 4.2-R libc.so.4. This
is because the /usr/include/sys/ and /usr/include/machine/ headers
(especially the syscall ones) used to compile the 4.2-R libc sources will
match the 4.0-R kernel. Interface changes (as exposed) in /sys/sys and
/sys/arch/include are one of the bigger ways to get a kernel and
userland out of sync.
However, incompatible is incompatible and it seems to me that we should
still bump the version of libc just to make sure people won't get into
a similar situation by copying supposedly compatible shared library.
Maybe but this is unix where we kinda give people all the rope the
need... Switching to a versioned API would probably help this issue.
But it increases the library and toolchain maintenance.
(If libc was at so.5 in the upgrade kit it at least wouldn't have
killed existing binaries.)
I guess that would be one approach... but I fear it will lead us to bump
the version at every release. I think this could increase support
questions.
By the way, if the conclusion is that we can't provide an upgrade kit
that will work for 4.0R (regardless of whether we bump libc or not),
I'll just replace that package with something that prints "sorry, we
can't support that system anymore, please upgrade".
If you've got space [and time] to build a special libc.so.4 for 4.[01]-R,
using 4.2 libc (only) sources, it should work well. Of course at some
point it is a hopeless cause, as there will be some change to the libc
sources that requires changes in /usr/include/{sys,machine}/ .
In the merging of xpg4 into libc using the various Binutils utils.
JDP would know more about the viability of this than I do.
--
-- David ([EMAIL PROTECTED])
GNU is Not Unix / Linux Is Not UniX
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
