Re: Chrooted telnet support in 4.x???
what would be even cooler is if we could jail() a user natively at login. I bet this patch could be easily modified to use jail() instead of chroot(). On Wed, 22 Mar 2000, Poul-Henning Kamp wrote: In message 051001bf942c$87e3fa40$[EMAIL PROTECTED], "Alejandro Ramirez" writes: Hi, Will FreeBSD 4.x will be able to chroot telnet sessions natively???, or are there any plans to integrate this patches to the base system: Investigate the jail(8) facility in 4.x, it is *far* stronger than anything chroot(2) has to offer. -- 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Why don't we use the download accelerator (http://www.lidan.com/) methodology and make simultaneous connections to the top 4 sites as discovered by ping? :) On Mon, 24 Jan 2000, Brad Knowles wrote: At 5:23 PM -0800 2000/1/21, Rodney W. Grimes wrote: You don't even need to modify the protocol. Just write a small tcp program that times the 3 way handshake on open to all the servers, take the one with the sortest time and spit that out for the user to stuff in his cvsupfile. Ahh, yes. But, the latency between the "master" server and the "slave" servers does not necessarily equal the latency between the cvsup client and the master or slave servers, and you want to be able to make intelligent choices based on more than *just* the network latency between the cvsup client and the servers -- if one is very close, but that one happens to be cvsup1 and is overloaded most of the time, then you want to be able to choose other servers that might not be quite so close, but which are much more lightly loaded. Small numbers of "test" data packets tell you very little about what the overall network performance is going to be like between any two sites -- you may have lots of highly bursty traffic on one route and a slightly higher latency but much more consistent level of traffic on another route. You may have small packets flying through a particular network, but when you go to actually transfer any data, you find that you get huge percentages of drops on large packets. You may have a very lightly loaded 64KB line between you and your first choice which shows up fantastically well on the "test" (both low latency and low quantity of drops), but which starts to suck huge boulders when it comes to actually transferring data. There are a lot of factors to be considered, and it seems to me that the best thing is to have some more intelligence in the client, so that it can do at least a first approximation as to network latency and available bandwidth between it and the various servers, and then this could be augmented by additional information that could be provided by cooperating servers that feed each other information about the status of the overall network from their perspective, etc -- These are my opinions and should not be taken as official Skynet policy _ |o| Brad Knowles, [EMAIL PROTECTED] Belgacom Skynet NV/SA |o| |o| Systems Architect, Mail/News/FTP/Proxy Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.13.11/726.93.11 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
lint not working on -current?
First of all, forgive me for being stupid, if that's what it turns out it was, but I can't seem to get lint to work on -current (though it works fine on -stable). lint -V pvselect.c pvselect.c: /usr/libexec/cpp -lang-c -undef -$ -C -Wcomment -D__FreeBSD__=4 -Dlint -D__lint -D__lint__ -D__unix -D__unix__ -D__i386 -D__i386__ -Wtraditional -Di386 pvselect.c /tmp/lint0.UT6044 cpp: Invalid option `-undef' uname -a FreeBSD [censored].com 4.0-2110-CURRENT FreeBSD 4.0-2110-CURRENT #0: Mon Jan 10 14:09:46 GMT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC i386 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
process hung in ttywri
I figured out how to reproduce the ttywri hang at will (I'm sure there are other ways, but this works for me 100%): 1) using SecureCRT and ssh2, ssh into your machine 2) run "find /" 3) click your mouse in the window and hold down. the scrolling will stop. hold this down for a few seconds. 4) let go of the mouse button, the buffer will flush and then the process will hang in ttywri: 2847 anthony4 0 936K 620K ttywri 0:00 0.00% 0.00% find Since I can reproduce this at will, on both stable and current, if anyone wants me to reproduce it and give the results of something, let me know. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anonymity, was: load spike strangeness
On Sun, 9 Jan 2000, Leif Neland wrote: While I do not agree with your idea of need of anonymity, I respect your need for it. Could you not, instead of using the handle "FreeBSD", which sortof already is taken :-), just assume a human name? The use of an obviously not human name makes it uncomfortable to communicate with you. If you would call you John Smith, or Thomas Jefferson if you want, you could much more easily hide your (hideous?) precence in the lists. Please? Yeah, like Mr. K. :) Leif K To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
