Re: jail support for ping, traceroute, etc.. crude hack
On Mon, Mar 17, 2003 at 10:06:27AM +0300, .@babolo.ru wrote: It is time to invent ping socket and traceroute socket in addition to tcp, udp, divert so on? Whilst this might seem nice, actually implementing so that it is both useful and safe is not easy. For a ping socket, this is reasonably easy if all you want is the ability to send ICMP ECHO REQUEST packets and receive any ICMP ECHO REPLY packets associated with previous request packets. It's not totally trivial because the kernel has to keep the state for outgoing packets to ensure that only the correct incoming packets are forwarded. (This is a security issue - you don't want somone finding out hosts someone outside that jail is pinging). Remember to allow for multiple responses to a single request and for long delays. You might also want to implement resource restrictions to prevent someone flooding the system with request packets. Not so easy to do but easy understandable for me. A traceroute socket is harder: There's no ICMP TRACEROUTE packet. Instead, traceroute(8) sends outgoing IP packets with varying TTL sizes and monitors incoming ICMP looking for check for HOST UNREACHABLE - TIME EXCEEDED IN TRANSIT packets. Again, the kernel would need to validate the incoming packets against outgoing packets. traceroute socket is just a curiosity. It seems to me better use UDP socket with some controls and ping socket from above. But way to obtain ping socket coupled with UDP socket is above my brain. Or may be more common way? Semiraw socket for ability send some classes of IP packets and seceive all induced ICMP ICMP ECHO REQUEST, any UDP and other protocols exept TCP with correct source IP address is probably secure enough for use by root in jail. In both cases, you also need to work out how to handle other random ICMP packets that be received as a result of the outgoing packets. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: make world + kernel with gcc 3.2?
On Sat, Mar 15, 2003 at 07:58:13PM +, Scott Mitchell wrote: On Sat, Mar 15, 2003 at 07:08:40PM +0100, Thierry Herbelot wrote: Le Saturday 15 March 2003 18:14, Avleen Vig a ?crit : I don't expect HUGE problems with making world, but am I asking for trouble if I make a new kernel with GCC3.2? good luck to you ! just have a look at the differences in the source code between current and stable to enable the compilation of current with gcc3 (FriBi -Stable will not compile with anything other than gcc 2.95) TfH I assume the OP installed gcc3 from ports...in this case the gcc2.95 system compiler will still be installed as well. True. I'm pretty sure that a kernel build will explicitly use the system compiler, True. and buildworld/buildkernel certainly do (I believe buildworld actually builds a fresh copy of gcc2.95 then uses that to build the rest of the system). True. As Thierry says, trying to build -stable with gcc3 is probably doomed to failure. Correct, but irrelevant, as shown above. The buildworld/buildkernel process will use the system gcc 2.95.x, and everything will go smoothly. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence is false. pgp0.pgp Description: PGP signature
¶éҤسÂѧ·ÓÊÔ觷Õè¤Ø³·ÓÍÂÙèÇѹ¹Õé ¾ÃØ觹Õé¡ç¨ÐàËÁ×͹Çѹ¹Õé
ËÒ¡¤Ø³ÅéÁàËÅÇ·Õè¨ÐÇҧἹ ÂèÍÁá»ÅÇèҤسÇҧἹ·Õè¨ÐÅéÁàËÅÇ ¨ÔÁ âÃËì¹ ¹Ñ¡»ÃѪÒÍѹ´Ñº 1 ¢Í§âÅ¡ àªè¹ ¤Ø³¤Ô´ÇèÒ㹪ÕÇÔµ¹ÕéàÃÒ¤§äÁèÁÕ·Ò§ÃÇ ¤Ø³¡çä¨ÐäÁèÁÕ·Ò§ÃÇÂàÅ ËÃ×Í ¤Ø³¤Ô´ÇèÒÊÑ¡Çѹ¶Ö§©Ñ¹µéͧÃÇÂá¹èæ ¨ÔÁ âÃËì¹ ºÍ¡ÇèÒ ¶éҤسÂѧ·ÓÊÔ觷Õè¤Ø³·ÓÍÂÙè·Ø¡Çѹ¹Õé ÍÕ¡ 3 »Õ¢éҧ˹éÒÅͧ¤Ô´´ÙÇèÒ ¤Ø³¨ÐÁÕâÍ¡ÒÊÃÇÂä´éËÃ×ÍäÁè ¶éҤӵͺ¤×Í ãªè ¤Ø³¡ÓÅѧ¨ÐÃÇ ¡çÂÔ¹´Õ¡Ñº¤Ø³´éǤÃѺ¤Ø³¡ÓÅѧ¨ÐÃÇÂáÅéÇ áµè¶éҤӵͺ¤×Í äÁè ¤Ø³äÁèÊÒÁÒöÃÇÂä´é ¤Ø³µéͧà»ÅÕè¹ÍÐäÃÊÑ¡ÍÂèҧ㹪ÕÇÔµ¤Ø³áÅéÇ ¨ÔÁ âÃËì¹ ºÍ¡ÍÕ¡ÇèÒ ¶éҤسÂѧ·ÓÊÔ觷Õè¤Ø³·ÓÍÂÙèÇѹ¹Õé ¾ÃØ觹Õé¡ç¨ÐàËÁ×͹Çѹ¹Õé ä»àÃ×èÍÂæäÁèÁÕ·ÕèÊÔé¹ÊØ´ ËÁÒ¤ÇÒÁÇèÒ -¶éÒÇѹ¹Õé¤Ø³ÂѧµéͧÇÔè§ËÒà§Ô¹ ¨èÒÂ˹ÕéµèÒ§æ -¶éÒÇѹ¹Õé¤Ø³Âѧ¶Ù¡à¨éÒ¹Ò¡´¢Õè ãªé§Ò¹ÍÂèҧ˹ѡ -¶éÒÇѹ¹Õé¤Ø³ÂѧËÒ·Ò§ÍÍ¡äÁèä´é Åͧà»Ô´âÍ¡ÒÊãËéµÑÇàͧ´Ù à»Ô´ã¨¢Í§¤Ø³ãËé¡ÇéÒ§áÅéÇà´Ô¹µÒÁàÃÒÁÒËÃ×Í»ÅèÍÂãËéâÍ¡ÒʹÕéËÅØ´ÅÍÂä» ¤Ø³ÊÒÁÒöà¢éÒä»´ÙÃÒÂÅÐàÍÕ´à¾ÔèÁàµÔÁáÅСÃÍ¡¢éÍÁÙÅà¾×èÍ¢ÍÃѺ¢éÍÁÙÅàº×éͧµé¹¿ÃÕ ! ä´é·Õè http://www.geocities.com/thaigetrich/easywork ¢ÍÍÀÑÂËÒ¡¢éͤÇÒÁ¹Õé¶Ù¡Êè§ä»Âѧ¤Ø³â´ÂºÑ§àÍÔ ËÒ¡¤Ø³äÁèµéͧ¡ÒÃÃѺ¢éͤÇÒÁ¹ÕéÍÕ¡¡ÃØ³Ò mail ÁÒ·Õè www.ecommerce.web1000.com/unsub
¶éҤسÂѧ·ÓÊÔ觷Õè¤Ø³·ÓÍÂÙèÇѹ¹Õé ¾ÃØ觹Õé¡ç¨ÐàËÁ×͹Çѹ¹Õé
ËÒ¡¤Ø³ÅéÁàËÅÇ·Õè¨ÐÇҧἹ ÂèÍÁá»ÅÇèҤسÇҧἹ·Õè¨ÐÅéÁàËÅÇ ¨ÔÁ âÃËì¹ ¹Ñ¡»ÃѪÒÍѹ´Ñº 1 ¢Í§âÅ¡ àªè¹ ¤Ø³¤Ô´ÇèÒ㹪ÕÇÔµ¹ÕéàÃÒ¤§äÁèÁÕ·Ò§ÃÇ ¤Ø³¡çä¨ÐäÁèÁÕ·Ò§ÃÇÂàÅ ËÃ×Í ¤Ø³¤Ô´ÇèÒÊÑ¡Çѹ¶Ö§©Ñ¹µéͧÃÇÂá¹èæ ¨ÔÁ âÃËì¹ ºÍ¡ÇèÒ ¶éҤسÂѧ·ÓÊÔ觷Õè¤Ø³·ÓÍÂÙè·Ø¡Çѹ¹Õé ÍÕ¡ 3 »Õ¢éҧ˹éÒÅͧ¤Ô´´ÙÇèÒ ¤Ø³¨ÐÁÕâÍ¡ÒÊÃÇÂä´éËÃ×ÍäÁè ¶éҤӵͺ¤×Í ãªè ¤Ø³¡ÓÅѧ¨ÐÃÇ ¡çÂÔ¹´Õ¡Ñº¤Ø³´éǤÃѺ¤Ø³¡ÓÅѧ¨ÐÃÇÂáÅéÇ áµè¶éҤӵͺ¤×Í äÁè ¤Ø³äÁèÊÒÁÒöÃÇÂä´é ¤Ø³µéͧà»ÅÕè¹ÍÐäÃÊÑ¡ÍÂèҧ㹪ÕÇÔµ¤Ø³áÅéÇ ¨ÔÁ âÃËì¹ ºÍ¡ÍÕ¡ÇèÒ ¶éҤسÂѧ·ÓÊÔ觷Õè¤Ø³·ÓÍÂÙèÇѹ¹Õé ¾ÃØ觹Õé¡ç¨ÐàËÁ×͹Çѹ¹Õé ä»àÃ×èÍÂæäÁèÁÕ·ÕèÊÔé¹ÊØ´ ËÁÒ¤ÇÒÁÇèÒ -¶éÒÇѹ¹Õé¤Ø³ÂѧµéͧÇÔè§ËÒà§Ô¹ ¨èÒÂ˹ÕéµèÒ§æ -¶éÒÇѹ¹Õé¤Ø³Âѧ¶Ù¡à¨éÒ¹Ò¡´¢Õè ãªé§Ò¹ÍÂèҧ˹ѡ -¶éÒÇѹ¹Õé¤Ø³ÂѧËÒ·Ò§ÍÍ¡äÁèä´é Åͧà»Ô´âÍ¡ÒÊãËéµÑÇàͧ´Ù à»Ô´ã¨¢Í§¤Ø³ãËé¡ÇéÒ§áÅéÇà´Ô¹µÒÁàÃÒÁÒËÃ×Í»ÅèÍÂãËéâÍ¡ÒʹÕéËÅØ´ÅÍÂä» ¤Ø³ÊÒÁÒöà¢éÒä»´ÙÃÒÂÅÐàÍÕ´à¾ÔèÁàµÔÁáÅСÃÍ¡¢éÍÁÙÅà¾×èÍ¢ÍÃѺ¢éÍÁÙÅàº×éͧµé¹¿ÃÕ ! ä´é·Õè http://www.geocities.com/thaigetrich/easywork ¢ÍÍÀÑÂËÒ¡¢éͤÇÒÁ¹Õé¶Ù¡Êè§ä»Âѧ¤Ø³â´ÂºÑ§àÍÔ ËÒ¡¤Ø³äÁèµéͧ¡ÒÃÃѺ¢éͤÇÒÁ¹ÕéÍÕ¡¡ÃØ³Ò mail ÁÒ·Õè www.ecommerce.web1000.com/unsub
Re: fgdg
Hi, Joerg Micheel wrote: On Mon, Mar 17, 2003 at 12:39:22PM +0300, sergej wrote: mozno li ustanovit% odnovremenno na odin disk: unix i windows, i kak jto sdelat%! I think it would be better if you will ask questions in English. Get yourself a copy of the Complete FreeBSD by Greg Lehey, which covers this subject very well. This question also belongs to freebsd-questions, not -hackers. In short, the configuration option is there with FreeBSD as delivered, but you need to take care on making the right steps at the right time. Starting off with BSD first is the better way to proceed, adding Windows later. If you setup at first FreeBSD and then add Windows you will lose FreeBSD's boot loader. And you will have to reinstall bootloader. You also could meet other problems. If your set incorrect (from FreeBSD's point of view) geometry for you hard disk and install freebsd 5.0 after Windows 2000, freebsd will fix windows partition entry and any reinstalletions or fix procedures of Windows will lead to nothing. Probably some last versions from 4.x branch have the same features, but the last 4.x version I worked with at home was 4.3. PS. I don't know if this bug was fixed in current versions. I am almost sure that it is not. Best regards, Roman Kurakin Joerg To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
vidcontrol(1) FreeBSD 5.0 on Laptop (fwd)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I posted this earlier to the [EMAIL PROTECTED] list and didn't seem to get any responces. Perhaps some of you might know the answer? I have searched for this on google (web/groups) and in the FreeBSD Mailing list archives. There seems to be no such answer or even a similar problem. - -- Forwarded message -- Date: Mon, 17 Mar 2003 11:32:15 -0600 (CST) From: Shane Kinney [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: vidcontrol(1) FreeBSD 5.0 on Laptop I just encountered a very strange problem with my notebook thats running 5.0-RELEASE and XFree86. Normally the regular color of the plain VT is a black background with a white forground. I have been running XFree86 on the laptop for about a month now. Every now and then when I close the laptop lid while XFree86 is still running, when I re-open the lid the screen is black and in some kinda suspend mode. The only reason I tell you this, is because I have been running FreeBSD on this laptop for 2.5 years without X and its never had a problem, now all of a sudden the vitrual terminal (not xterm) colors are outta wack. On a side-note, XFree86 still works just as good as it did before this all happened. Anyway, I was meaning to disable the suspend feature in the BIOS. But the last time it went into the suspend, I rebooted the box, and when it started back up the background of the VT is blue and the forground is black. I did do this command: `vidcontrol white black`, and it stays with the blue background and the black forground. I also did a `vidcontrol show`, and the output for that is also incorrect. It's almost as if XFree86 somehow munged the original values for vidcontrol are set to. Do any of you know where these values might be held? Or has anyone seen something like this before? Does any one know how to fix this? Thanks a ton for any help. ~Shane Kinney Build Ramps, Not Bombs. pgp key: http://www.freebsdhackers.net/pgp -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE+djgUIyUr/yoGQnYRAgw0AJ9ktyVOUzYFc1RJzp2SAYwrVphrcwCbBVAy N+S7tPc6jQ4AfxZQIvf+fQ8= =9VTE -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: making CVS more convenient
Nate Williams wrote: That's the plan for the next stage, provided that the first stage goes well. I'm yet to play with CVSup and see if it can be integrated there (as with system()) easily without making a lot of changes to CVS itself. Otherwise I'm aftarid it's going to be a large amount of work to duplicate this functionality :-( Another choice is to have the commit be also made to the 'cache' if and only if the remote (master) respository has accepted the commit. That way, the commit is made in both repositories using the same algorithm, so in essence they should be in sync. Yes, makes sense. Yet another idea is to be able to make local commits with committing them to the central remote repository later. I'd do the reverse, since the possibility of synchronization problems are a huge deal. Imagine if someone 'snuck' in and made a commit in the master tree after your local commit was made, but before 'later' occurred and your cache pushed it out to the master tree. It gets handled in the same way as now: I believe, CVS checks whether the checked-out version matches the top of the branch, and if it does not then it refuses to commit and requires you to make an update. So the same thing can be done for a local branch: check that its base version is still the top of the real branch, and if so then commit. Otherwise require an update/merge. If you only allow the commit if it can occur locally, you're ensuring that the cache can't get out of date with local changes. I tried something like the above (cause it was easier to implement), and it worked most of the time. However, the times it didn't work it was a royal pain in the *ss to cleanup and get the original commit back out. Maybe I just was not clear: I think that making the commits in the local copy on the real top of the tree is a quite bad idea. All I want to get is some temporary versioned storage to play around while I work on the code. After the code gets finished, it gets committed to the master repository just as it committed gets now. Now I have to use RCS locally for the temporary in-delevopment versions of file. Would be nice to have a kind of a local branch which can be later committed as a whole - in one commit per file, or by duplicating all the intermediate versions with their messages. Agreed. The downside to the above method is that it requires network access to make a commit. However, it certainly simplifies the problem set. :) :) Well, at least the commit would get done in one batch (of course, unless a conflict happens). -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: making CVS more convenient
That's the plan for the next stage, provided that the first stage goes well. I'm yet to play with CVSup and see if it can be integrated there (as with system()) easily without making a lot of changes to CVS itself. Otherwise I'm aftarid it's going to be a large amount of work to duplicate this functionality :-( Another choice is to have the commit be also made to the 'cache' if and only if the remote (master) respository has accepted the commit. That way, the commit is made in both repositories using the same algorithm, so in essence they should be in sync. Yes, makes sense. Yet another idea is to be able to make local commits with committing them to the central remote repository later. I'd do the reverse, since the possibility of synchronization problems are a huge deal. Imagine if someone 'snuck' in and made a commit in the master tree after your local commit was made, but before 'later' occurred and your cache pushed it out to the master tree. It gets handled in the same way as now: I believe, CVS checks whether the checked-out version matches the top of the branch, and if it does not then it refuses to commit and requires you to make an update. So the same thing can be done for a local branch: check that its base version is still the top of the real branch, and if so then commit. Otherwise require an update/merge. Except that it's possible that the 'local' cache is out-of-date w/respect to the remote repository, say if someone made a commit to it since the last 'synchronization' of the local cache. You don't want that commit to happen, since it should be allowed because the file is really not up-to-date w/respect to the master. The worst case is the committed change would conflict with the as-yet-unseen change on the master, so allowing the local user to commit it means that when the 'cache' attempts to commit it later, it will fail, and the 'cache code' is required to figure out how to extract the commit from the local cache, update the local cache, re-apply the (now conflicing) commit back to the local cache and somehow inform the user at a later point. *UGH* If you only allow the commit if it can occur locally, you're ensuring that the cache can't get out of date with local changes. I tried something like the above (cause it was easier to implement), and it worked most of the time. However, the times it didn't work it was a royal pain in the *ss to cleanup and get the original commit back out. Maybe I just was not clear: I think that making the commits in the local copy on the real top of the tree is a quite bad idea. I think it's a good idea *IF and only IF* the commit to the remote tree works. That way, the local user isn't required to re-synchronize his cached tree agains the master tree, since their is a high liklihood that after the commit the user will also want to continue working on the same files. If no re-sychronization occurs, as soon as an 'cvs update' is done, the local cache must either re-synchronize itself (doing the exact same work as if it just done the commit), or the newly committed change will be reverted back out, since the local cache will now be out-of-date. I want to get is some temporary versioned storage to play around while I work on the code. After the code gets finished, it gets committed to the master repository just as it committed gets now. What happens to the local cache *right after* the commit occurs? In essence, it's no longer valid right after a commit, since it's now out-of-date with the master (it doesn't include the newly committed changes). Now I have to use RCS locally for the temporary in-delevopment versions of file. Would be nice to have a kind of a local branch which can be later committed as a whole - in one commit per file, or by duplicating all the intermediate versions with their messages. Agreed. The downside to the above method is that it requires network access to make a commit. However, it certainly simplifies the problem set. :) :) Well, at least the commit would get done in one batch (of course, unless a conflict happens). Right, it's a step in the right direction. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: making CVS more convenient
Terry Lambert wrote: Sergey Babkin wrote: Nate Williams wrote: [ ... CVS cache and cache coherency ... ] Yet another idea is to be able to make local commits with committing them to the central remote repository later. Now I have to use RCS locally for the temporary in-delevopment versions of file. Would be nice to have a kind of a local branch which can be later committed as a whole - in one commit per file, or by duplicating all the intermediate versions with their messages. Not really possible, without CVSup coming onto a vendor branch instead Actually, I was thinking of the opposite: doing all the changes on a vendor branch (or in some separate local repository altogether), then merging them into the main branch. Think of the following sequence that can be used now: cvs co rcs ci # save the baseline #... some modifications done rcs ci #... more modifications rcs ci # then someone committed another change to the repository and we want # to merge that change in cvs update # do the manual merge if neccessary rcs ci # save the merged version #... more modifications rcs ci # OK, let's suppose that our changes are finally complete, and nobody # else has committed any other changes in between cvs ci So pretty much all I want is to make this procedure a bit more convenient, able to handle whole subdirectories as opposed to separate files. As a model consider this: suppose we build a separate copy of the CVS binary, called mycvs that has the following differences from the normal CVS: 1. Instead of the variable CVSROOT it uses MYCVSROOT 2. Instead of the metadata subdirectory name CVS it uses the name MYCVS 3. It never touches any of the keywords (such as $Id etc.) 4. When asked to add a file, it automatically creates the whole path of intermediate directories for it. (How does it know where the checked-out tree starts ? There are many more or less obvious and convenient ways to do that, so let's leave this issue alone for now). Then in the example above you can do export MYCVSROOT=~/tmp/cvsroot mycvs init And do everyhing as in the previous example, only replacing rcs with mycvs (and obviously you wold need to do mycvs add before the fiest mycvs ci). of verbatim copying of the repository. Incoherent: ,---. ,---. | Main | cvsup ---| Cache | | Repo | | Repo | `---' `---' ^ | |cvs co cvs ci | | V | ,---. | | Work | `---| Copy | `---' Why is it incoherent ? CVS checks that the version obtained by cvs co and then modified is still the top of the tree. If it's not, it will refuse to commit and will request you to do an update. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: making CVS more convenient
Nate Williams wrote: It gets handled in the same way as now: I believe, CVS checks whether the checked-out version matches the top of the branch, and if it does not then it refuses to commit and requires you to make an update. So the same thing can be done for a local branch: check that its base version is still the top of the real branch, and if so then commit. Otherwise require an update/merge. Except that it's possible that the 'local' cache is out-of-date w/respect to the remote repository, say if someone made a commit to it since the last 'synchronization' of the local cache. You don't want that commit to happen, since it should be allowed because the file is really not up-to-date w/respect to the master. The worst case is the committed change would conflict with the as-yet-unseen change on the master, so allowing the local user to commit it means that when the 'cache' attempts to commit it later, it will fail, and the 'cache code' is required to figure out how to extract the commit from the local cache, update the local cache, re-apply the (now conflicing) commit back to the local cache and somehow inform the user at a later point. *UGH* Yes, this is way too complicated and error-prone. This is why I don't want to change the cache without changing the master in the same way first. If you only allow the commit if it can occur locally, you're ensuring that the cache can't get out of date with local changes. I tried something like the above (cause it was easier to implement), and it worked most of the time. However, the times it didn't work it was a royal pain in the *ss to cleanup and get the original commit back out. Maybe I just was not clear: I think that making the commits in the local copy on the real top of the tree is a quite bad idea. I think it's a good idea *IF and only IF* the commit to the remote tree works. That way, the local user isn't required to re-synchronize his cached tree agains the master tree, since their is a high liklihood that Agreed. So the commit would essentially work as a commit plus resynchronization of a subset of files in the cache. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: making CVS more convenient
It gets handled in the same way as now: I believe, CVS checks whether the checked-out version matches the top of the branch, and if it does not then it refuses to commit and requires you to make an update. So the same thing can be done for a local branch: check that its base version is still the top of the real branch, and if so then commit. Otherwise require an update/merge. Except that it's possible that the 'local' cache is out-of-date w/respect to the remote repository, say if someone made a commit to it since the last 'synchronization' of the local cache. You don't want that commit to happen, since it should be allowed because the file is really not up-to-date w/respect to the master. The worst case is the committed change would conflict with the as-yet-unseen change on the master, so allowing the local user to commit it means that when the 'cache' attempts to commit it later, it will fail, and the 'cache code' is required to figure out how to extract the commit from the local cache, update the local cache, re-apply the (now conflicing) commit back to the local cache and somehow inform the user at a later point. *UGH* Yes, this is way too complicated and error-prone. This is why I don't want to change the cache without changing the master in the same way first. I think we're in *violent* agreement at this point. :) If you only allow the commit if it can occur locally, you're ensuring that the cache can't get out of date with local changes. I tried something like the above (cause it was easier to implement), and it worked most of the time. However, the times it didn't work it was a royal pain in the *ss to cleanup and get the original commit back out. Maybe I just was not clear: I think that making the commits in the local copy on the real top of the tree is a quite bad idea. I think it's a good idea *IF and only IF* the commit to the remote tree works. That way, the local user isn't required to re-synchronize his cached tree agains the master tree, since their is a high liklihood that Agreed. So the commit would essentially work as a commit plus resynchronization of a subset of files in the cache. *grin* I love it when a plan comes together. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
section of source code handling reclamation of KVM
Hello, I'd like to learn more about how FreeBSD handles running out of KVM. We're running a 4GB of RAM system with no swap being used, but we're run out of KVM and I'd like to go read through the code to see how this is handled so I can be on the lookout for potential issues that may come up. %sysctl -a |grep kvm vm.kvm_size: 1065353216 vm.kvm_free: 0 Could someone direct me to the section of the 4.7 source tree that handles additional KVM requests when vm.kvm_free=0 so I can go read up on the process? Thanks in advance. Sincerely, Andrew Kinney President and Chief Technology Officer Advantagecom Networks, Inc. http://www.advantagecom.net To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
NFS performance tuning
Hi Folks, This is an open ended email with a question about how to increase performance of a 4-stable system running in a high-load environment. The src is current as of: FreeBSD 4.8-RC #1: Sun Mar 16 15:44:01 Running top on the system: PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 93 root 2 0 360K 148K RUN197:27 48.49% 48.49% nfsd 94 root 2 0 360K 148K RUN 28:36 5.71% 5.71% nfsd 96 root 2 0 360K 148K RUN 10:37 3.66% 3.66% nfsd 95 root 2 0 360K 148K RUN 18:34 3.27% 3.27% nfsd 98 root 2 0 360K 148K RUN 6:25 1.03% 1.03% nfsd 97 root 2 0 360K 148K RUN 8:17 0.83% 0.83% nfsd 3201 admin 30 0 1908K 1056K RUN 0:00 1.19% 0.73% top 99 root 2 0 360K 148K RUN 5:21 0.63% 0.63% nfsd 101 root 2 0 360K 148K RUN 4:18 0.20% 0.20% nfsd and a ps a minute or so later: PID PPID UID %CPU %MEM STAT TIME COMMAND 92 1 0 0.0 0.0 Is 0:00.00 nfsd: master (nfsd) 9392 0 45.3 0.0 R199:46.61 nfsd: server (nfsd) 9492 0 5.0 0.0 R 28:57.60 nfsd: server (nfsd) 9592 0 2.1 0.0 R 18:48.99 nfsd: server (nfsd) 9692 0 1.1 0.0 R 10:45.36 nfsd: server (nfsd) 9792 0 0.3 0.0 R 8:23.25 nfsd: server (nfsd) 9892 0 0.4 0.0 R 6:30.47 nfsd: server (nfsd) 9992 0 0.2 0.0 R 5:25.05 nfsd: server (nfsd) 10192 0 0.2 0.0 R 4:21.38 nfsd: server (nfsd) The nfsd processes are almost always Runnable. The box is an athlon MP 2200+ based system on a tyan S2466 motherboard (http://www.tyan.com/products/html/tigermpx.html) with only one processor currently installed, 2Gig of Ram. The filesystem being served out lives on an Adaptec 5400S Raid controller: aac0: Adaptec SCSI RAID 5400S port 0x1000-0x10ff mem 0xe800-0xe8001fff irq 9 at device 9.0 on pci0 aac0: StrongARM SA110 233MHz, 128MB cache memory, required battery present aac0: Kernel 1.0-0, Build 5262, S/N 6b1830 aacd1: RAID 5 on aac0 aacd1: 769984MB (1576929024 sectors) The system is located on 5 different networks: (netstat -i) Name Mtu Network AddressIpkts IerrsOpkts Oerrs Coll gx0 1500 Link#100:90:27:a1:5d:0b 12056041 0 14715548 0 0 gx0 1500 192.168.30192.168.30.250 12055944 - 14715450 - - gx1 1500 Link#200:90:27:a1:44:5a 2269975 0 2753705 0 0 gx1 1500 192.168.31192.168.31.250 2269878 - 2753607 - - fxp0 1500 Link#300:02:b3:60:b5:3a 241440300 0 246915204 946 0 fxp0 1500 10.14.2/24bb03na1a.hsr.sa 241447878 - 246924642 - - fxp1 1500 Link#400:02:b3:4a:76:e6 117933878 706 122043638 921 0 fxp1 1500 10.14.3/24bb03na1b.hsr.sa 117939587 - 122051034 - - fxp2 1500 Link#500:02:b3:60:a8:9d 303742731 0 310860180 901 0 fxp2 1500 10.14.4/24bb03na1c.hsr.sa 303760088 - 310879510 - - (The gx cards are 1000baseSX full-duplex). (The fxp cards are 100baseTX full-duplex). and from netstat -m: %netstat -m 916/2512/34816 mbufs in use (current/peak/max): 894 mbufs allocated to data 22 mbufs allocated to packet headers 729/1160/8704 mbuf clusters in use (current/peak/max) 2948 Kbytes allocated to network (11% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines and from nfsstat: Server Info: Getattr SetattrLookup Readlink Read WriteCreateRemove 31122 62636 600335411186827 5952269815008 90198 59781 Rename Link Symlink Mkdir Rmdir Readdir RdirPlusAccess 22236 015 8067 1598919886248 78463316 MknodFsstatFsinfo PathConfCommitGLeaseVacate Evict 0242190 8 0149734 0 0 0 Server Ret-Failed 591695228 Server Faults 0 Server Cache Stats: Inprog Idem Non-idemMisses 228 1165852 686794492 Server Lease Stats: Leases PeakL GLeases 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 815008815008 0 The system holds alot of c and h files along with other pretty static data. The performance of the system is not bad, but I'm curious about what folks might do to tune it up some. Anyways, comments welcome! -john To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: making CVS more convenient
Sergey Babkin wrote: Terry Lambert wrote: Not really possible, without CVSup coming onto a vendor branch instead Actually, I was thinking of the opposite: doing all the changes on a vendor branch (or in some separate local repository altogether), then merging them into the main branch. Think of the following sequence that can be used now: [ ... ] # OK, let's suppose that our changes are finally complete, and nobody # else has committed any other changes in between cvs ci Suppose someone has? If you are so out of touch with the net you need a cache, you are probably going to get a conflict, because people are tweaking things all the time, sometimes, it seems, rearranging the deck chairs to get their name in CVS lights. 8-). So pretty much all I want is to make this procedure a bit more convenient, able to handle whole subdirectories as opposed to separate files. That's reasonable, but... you're rcs ci is a killer; it assumes a local repostory in parallel. I guess you want a multicvs, which does checkins remotely or locally? If you want all of your checkins checked in, then you could do this with a shell script wrapper that knew about link up on your network interfaces. Is that a possible solution for you? As a model consider this: suppose we build a separate copy of the CVS binary, called mycvs that has the following differences from the normal CVS: 1. Instead of the variable CVSROOT it uses MYCVSROOT 2. Instead of the metadata subdirectory name CVS it uses the name MYCVS 3. It never touches any of the keywords (such as $Id etc.) 4. When asked to add a file, it automatically creates the whole path of intermediate directories for it. (How does it know where the checked-out tree starts ? There are many more or less obvious and convenient ways to do that, so let's leave this issue alone for now). Then in the example above you can do export MYCVSROOT=~/tmp/cvsroot mycvs init And do everyhing as in the previous example, only replacing rcs with mycvs (and obviously you wold need to do mycvs add before the fiest mycvs ci). That's actually grosser than the rcs version (IMO)... of verbatim copying of the repository. Incoherent: [ ... diagram ... ] Why is it incoherent ? CVS checks that the version obtained by cvs co and then modified is still the top of the tree. If it's not, it will refuse to commit and will request you to do an update. I left out the (I thought) obvious part; ket me fix it: ,---.-cvsup(1)-,---. | Main | cvsup(2)-| Cache |--. | Repo |[CONFLICT] | Repo | | `---' `---' | ^ | | |cvs co | cvs ci(2) | cvs ci(1) [CONFLICT] V | cvs ci(3) ,---. | | | Work | | `---| Copy |---' `---' Order: cvsup(1) cvs co cvs ci(1) cvs ci(2) [CONFLICT] [FIX] cvs ci(3) cvsup(2) [CONFLICT] In other words, you can't order commits with conflicts, without going to the main repo first in call cases. That destroys your intended disconnected use. The first time you get a conflict, your MYCVSROOT repository is blown, and you won't be able to resyncronize it, without replacing ,v and CVS/* file contents. In other words, any time, there is a checkin to main repository conflict, your foot goes bye bye... Make sense? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: making CVS more convenient
Dag-Erling Smrgrav wrote: Sergey Babkin [EMAIL PROTECTED] writes: A similar thing may be achieved by checking the files out from the local repository and doing any modification command with option -d. But that's troublesome and inconvenient. Read the manual page for the shell you're using, with particular emphasis on the 'alias' builtin command. I think that it's not a good solution, for several reasons: * Using -d for an alternative repository is pretty much a dirty trick, and undocumented one too. But the purpose itself is quite valid, transparent, and simple and I think that it's better to make it obvious and easy to use than tricky. I like the principle simple things should be easy, complex things should be possible. * There may be scripts that run cvs commands, which scripts absolutely don't need to know about a cache repository underneath. * I don't like the layers of workaround scripts built over other workaround scripts. I think that it's something of an aftermarket Unix syndrome: when you can trick a tool to do what you want and wrap it into a script for the ease of use but can't change the tool to do what you need directly, in a simple way. The original Unix (both Bell Labs and BSD) was not like this: when the people made some useful addition, they just got it right into the base system. Now with open source OSes we can do the same thing and not look for extra pain with wrapper scripts. * Getting the cache repository support right into CVS allows to modify the CVS commands in future to take advantage of this knowledge. For example, commit may not just check the modification date and send the file to the server if it has changed, but instead also compare the file with the one in the cache repository and send it to the server only if the file has actually changed. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
