Re: sonewconn: pcb 0xfffffe00c7223498: Listen queue overflow
In message 798639e66426509cd53d1f2a1c1d5...@intertainservices.com, Mike Jakubik writes: Hello, I updated our main server to 9.2-STABLE today and afterwards I noticed a bunch of these messages, does anyone know what they mean? I was unable to find anything on this error message. Things appear to be working OK so far. Sep 30 22:08:56 illidan kernel: sonewconn: pcb 0xfe00c7223498: Listen queue overflow: 193 already in queue awaiting acceptance Sep 30 22:12:27 illidan kernel: sonewconn: pcb 0xfe00c7223498: Listen queue overflow: 193 already in queue awaiting acceptance Use netstat -nAa to match the reported pcb (protocol control block) to the IP address and port. Then use that to work out which daemon is not keeping up. Mark Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Bind in FreeBSD, security advisories
In message 9b0056db5b760c755dd4acc45bfbd1ad.authentica...@ultimatedns.net, C hris H writes: On 30.07.2013, at 19:49, Peter Maxwell pe...@allicient.co.uk wrote: I personally prefer qmail over sendmail but I wouldn't suggest qmail should be in base for the reason that sendmai l is the de facto standard on *nix shaped systems. One can argue that BIND is the de facto standard on *nix shaped systems too . Considering the topic, and how many times it's come up. I'm not sure that's a nything to be proud of. ;) Given not all CVE's are created equal and given the amount of internal self consistancy checks (all of which kill the server if they don't pass (and push the CVSS score to 7.x)) there are in BIND the number of advisaries is actually very small. Yes, this was a internal self consistancy check failing. We are human and despite code reviews, unit and system tests, static analysis checkers etc. some errors do make it through. Mark Daniel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sendmail vs ipv6 broken after upgrade to 9.1
In message 20130110002257.ga84...@anubis.morrow.me.uk, Ben Morrow writes: Yeah; I agree that the v4-mapped option is pretty useless (even when using a stack which supports it). I suspect the IETF people were trying too hard to account for the case of a v6-only stack talking to the v4 Internet, when AFAIK there aren't any v6-only stacks yet, nor are there likely to be for the forseeable future. That's why I think Sendmail ought to be changed to pass 0 flags, so it doesn't see v4-mapped addresses at all: after all, there's little point binding separate v4 and v6 sockets if the v6 socket is just going to end up bound to a v4-mapped address. Mapped addresses are for dual stack hosts and sockets with IPV6_ONLY turned off. They work much better when the IPv4 side of the stack has been upgraded to support all of the new features of IPv6 socket api like packet info so that the application doesn't need to remember if it is talking to a IPv4 or IPv6 destination. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Does / Is anyone maintaining CVS for FreeBSD?
In message 50e5a7d1.4080...@freebsd.org, Matthias Andree writes: Am 03.01.2013 16:36, schrieb Eitan Adler: On 3 January 2013 02:32, Matthias Andree mand...@freebsd.org wrote: Please do not quote addresses. Not all web archives and copies hide them properly. Hiding email addresses is useless for spam control. Obfuscating them makes it harder to follow a conversation. Anyways it's useless baggage in the presence of real names. Garbage. Real names are *not* unique. Email address are disambiguators. Threading is to happen along In-Reply-To: and References: headers - they were made exactly for that - and not after body content. I take care to reply to the message I am referring to so that those headers are intact. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: IPv6 default route. Can't see the wood for the trees.
In message 503bcb0a.6000...@freebsd.org, Doug Barton writes: On 8/27/2012 12:27 PM, Christian Laursen wrote: On 08/27/12 21:03, John Hawkes-Reed wrote: On 27/08/2012 19:06, Christian Laursen wrote: On 08/27/12 18:49, John Hawkes-Reed wrote: rc.conf: (I'm not convinced that obfuscating the addresses is worth the confusion) ipv6_gateway_enable=YES ip6addrctl_verbose=YES rtadvd_enable=YES rtadvd_interfaces=rl0 ipv6_cpe_wanif=pcn0 ipv6_defaultrouter=2001:470:1f0a:b5a::1 gif_interfaces=gif0 gifconfig_gif0=192.168.1.100 216.66.80.30 ifconfig_gif0_ipv6=inet6 2001:470:1f0a:b5a::2 2001:470:1f0a:b5a::1 prefixlen 128 ifconfig_pcn0_ipv6=inet6 2001:470:1f0b:b5a::4 prefixlen 64 ifconfig_rl0_ipv6=inet6 2001:470:1f0b:b5a::3 prefixlen 64 -accept_rtadv It looks like you are trying to use the /64 used for your tunnel on the inside network. That's probably what causes the problem. You should use the Routed /64 on the inside. If you need more than one /64, you can request a /48. I think I am. The endpoints are ...:1f0A: and the /64 is ...:1f0B: Sorry, my bad. Are pcn0 and rl0 both connected to internal networks? Having the same /64 configured on both is probably bad. Why would it be? Unless you bridge the two interface, yes. Which interface do you start ND on? For the OP, here is my ipv6 configuration. tx0 is the internal net and is running with ULA as well as the /64 from HE. sis0 is the external cable connection. gif0 is the tunneled connection back to HE. sft0 sends 6to4 reply traffic directly it is out bound only. % ifconfig -a inet6 tx0: flags=28943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::2e0:29ff:fe19:c02d%tx0 prefixlen 64 scopeid 0x1 inet6 2001:470:1f00:820:2e0:29ff:fe19:c02d prefixlen 64 inet6 2001:470:1f00:820:: prefixlen 64 anycast inet6 fd92:7065:b8e:0:2e0:29ff:fe19:c02d prefixlen 64 inet6 fd92:7065:b8e:: prefixlen 64 anycast sis0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::209:5bff:fe1e:e13e%sis0 prefixlen 64 scopeid 0x2 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 gif0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1280 tunnel inet 211.30.172.21 -- 64.71.128.82 inet6 fe80::2e0:29ff:fe19:c02d%gif0 prefixlen 64 scopeid 0x8 inet6 2001:470:1f00:::5a1 -- 2001:470:1f00:::5a0 prefixlen 128 stf0: flags=1001UP,LINK0 mtu 1280 inet6 2002:d31e:ac15:: prefixlen 16 anycast % -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: less and vi fail on file whose name begins with +
This is not a bug. Both vi and less have + command line arguements. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You NOT Using FreeBSD ?
In message 7b6e5361-b109-498e-b22f-96a94dec3...@mac.com, Chuck Swiger writes: Hi, Dave-- On Jun 11, 2012, at 4:35 PM, Dave Hayes wrote: [ ... ] Do I have this wrong? Anyone see a problem with this picture? What can we do to just upgrade in a safe fashion when we want to? Two things help tremendously: #1: Have working backups. If you run into a problem, roll back the system to a working state. If you cannot restore a working system easily, fix your backup solution until you can rollback easily. #2: Have a package-building box and test builds before installing new package builds to other boxes. Your downtime for upgrades to the rest of your boxes become minimized. Note: this doesn't require multiple physical systems to do. A jail / chroot area will give you a perfectly fine build / test system for ports. It just uses a bit of disk space. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You NOT Using FreeBSD?
In message 1805884.wjzbqif...@x220.ovitrap.com, Erich writes: Hi, On 06 June 2012 0:42:47 Mark Andrews wrote: In message 1541214.zfrdxxb...@x220.ovitrap.com, Erich writes: Hi, On 05 June 2012 1:09:50 Mark Linimon wrote: On Tue, Jun 05, 2012 at 01:00:45PM +0700, Erich wrote: All of these, with the exception of HEAD (which is always a valid tag ), only apply to the src/ tree. The ports/, doc/, and www/ trees are not branched. If you create a branch, you must create a tag for that branch. However, you can create a tag without creating a branch. That is what is done for the ports tree. I found now the location where this information is missing for beginners. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.htm l I simply cannot believe that beginners would expect this information to f ind this in the section for updating the kernel. Erich Because, while you believe it is better to roll back to the release point it really isn't. The ports tree is rarely broken for long. When it is broken people will tell you to roll back to a good date and give you the date to use. I've had to roll back a couple of times in 11+ years of updating and never to a release point. What is there is good advice. Use a up-to-date ports tree. If it is broken wait a days or so and try again. If it is still broken report the problem using send-pr. you will find thousands of notes that people should not run bleeding edge when it comes to the kernel. But people are forced to run bleeding edge on the ports. The kernel and ports are very different things. On the bleeding edge the kernel may not even boot and if it boots it may corrupt the entire disk requiring you to reinstall and recover from backups. Ports don't normally get added unless they build and run. Occasionally there are integration issues because one cannot test the billions if not trillions of possible port combinations. Remember almost every port is already released software that has already gone through alpha and beta testing. Those that arn't are clearly marked as such. The documentation than even states that there is no fall back. You state it as being just normal to wait for a week or more until the problem is solved. I cannot imagine that people who come to FreeBSD and get trapped somehow will stick to it then. If you report a bug to Oracle or Microsoft you won't get a fix within a week. It just doesn't happen unless you are paying very big dollars and might not happen even then as it can take weeks to find the cause of a bug even with a team working 7x24 to find it. They might will ask on this list just to learn that there is no help available. Just wait. People who have to make decisions what operating system should be used on their workplaces will not like this and stick with whatever they have. Yet there are plenty of places that do run FreeBSD. They understand the limitations and accept them. I believe that this is a very good user repellent. Remember you don't have to use the ports system. You can install software without using ports. The ports system just saves you time. Erich -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You NOT Using FreeBSD?
In message 1541214.zfrdxxb...@x220.ovitrap.com, Erich writes: Hi, On 05 June 2012 1:09:50 Mark Linimon wrote: On Tue, Jun 05, 2012 at 01:00:45PM +0700, Erich wrote: All of these, with the exception of HEAD (which is always a valid tag), only apply to the src/ tree. The ports/, doc/, and www/ trees are not branched. If you create a branch, you must create a tag for that branch. However, you can create a tag without creating a branch. That is what is done for the ports tree. I found now the location where this information is missing for beginners. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.html I simply cannot believe that beginners would expect this information to find this in the section for updating the kernel. Erich Because, while you believe it is better to roll back to the release point it really isn't. The ports tree is rarely broken for long. When it is broken people will tell you to roll back to a good date and give you the date to use. I've had to roll back a couple of times in 11+ years of updating and never to a release point. What is there is good advice. Use a up-to-date ports tree. If it is broken wait a days or so and try again. If it is still broken report the problem using send-pr. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You NOT Using FreeBSD?
In message 4fcd23fe.20...@zedat.fu-berlin.de, O. Hartmann writes: Well, and repeatedly (no offense!) I will point out in this case, that I was FORCED having the latest software by the ports system! That it a difference in having running FreeBSD CURRENT on my own risk, or FreeBSD-STABLE due to new hardware and new drivers only supported by those and having a regular port update, which blows up the system because of the newest software! You were not forced to use the latest. You can quite easily use years old ports trees if you want to. I just installed a port using a tree from October 2011. I could have upgraded the ports tree to the latest and greatest but I choose not to. I take the burden of having not an easy life, but this, what is expected from so many users of FreeBSD, is simply beyond ... There are also binary packages available. Either stick to releases, or put up with lots of compiling etc-- you should not complain because of self-inflicted problems. As I repeatedly have to point out in this case - the issue is not with STABLE and CURRENT, it is also with RELEASE. And as it has been pointed out herein so many times: FreeBSD ports lack in a version tagging. Version tagging is just a convient way to get a snapshot at a particular point in time unless you create branches that are them made stable by doing a release engineering process on the branch. This would require rules like don't make a change unless it is to fix something that is broken. It would also require a lot of man power. If you are willing to pay salaries for people to do this then I'm sure there are people who would do the job. The ports system has to ability to set the ports tree to any point in time in its existance. You can then build all the indexes as they were at that point in time. How would you suggest avoiding the problems we face with the ports by being sticky on RELEASE, if the problem is spread over all branches? Please remember that we do compile packages for release, or if more up to date packages are required you can use the stable package sets which are rarely over five days or so. If it is about the binary packages - then you're right. Stick with RELEASE and binary packages - if available (the mentioned office packages are often much delayed). In such a case one is better with a binary spread version of an OS and this would exactly hit the subject of the thread: Why NOT using ... blablabla Chris At the end, I'd like to see more care about the way ports get updated. There is no way to avoid messes like described at this very moment. And it is a kind of unedifying . And I'd like to be able to world hunger and to see FTL travel. One doesn't have to live at the bleeding edge with ports if one doesn't want to even when compiling. One can live a day, a week, a month behind the bleeding edge and allow other to hit problems and report them. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You NOT Using FreeBSD?
In message 3506767.fvm2kmt...@x220.ovitrap.com, Erich writes: Hi, On 05 June 2012 11:24:25 Mark Andrews wrote: Version tagging is just a convient way to get a snapshot at a particular point in time unless you create branches that are them we do not ask for more. There should be only one difference to a snapshot. As snapshot has a date. No matter in what state the ports tree was, it is in th at state in the ports tree. If user - especially the one not so fit in this a spect - want to use a snapshot, it will be difficult to impossible to figure out which one they need. If version numbers would be introduced, it would be ok to use the version num ber of the FreeBSD and have only version available which reflect the release version of the ports tree. It's already there. If you want the ports as of FreeBSD 4.x EOL then the tag is RELEASE_4_EOL. If you want ports as of FreeBSD 9.0 then the tag is RELEASE_9_9_0. People here want to make always a perfect system. People like me want to have some small things in there available with a click. As the ports trees are there anyway, only the direct link to the snapshot of that day or a version number in the ports tree would be needed to make this a vailable for people who just want to use FreeBSD. Please note, I do not want any extra work spend here to make this perfect. I only want a simple way to fall back to a big net which is not that old from w hich the user can restart. You can add a huge note to the links stating the risks. This is all fine. There is another reason why I ask for this. I noticed a long time ago that th e ports are in a better shape around the release date of a new version. So, I try to get it always around the release dates. But, some times - you know ho w life is - I miss this date. It does not kill me but it leads some times to extra work steps I can do but I see the problems people will face who know Fr eeBSD not that well. One doesn't have to live at the bleeding edge with ports if one doesn't want to even when compiling. One can live a day, a week, a month behind the bleeding edge and allow other to hit problems and report them. How is this done with the knowledge of a beginner? One reads the documentation. Erich -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You NOT Using FreeBSD?
In message 2490439.ec638ti...@x220.ovitrap.com, Erich writes: Hi, On 05 June 2012 12:48:20 Mark Andrews wrote: In message 3506767.fvm2kmt...@x220.ovitrap.com, Erich writes: On 05 June 2012 11:24:25 Mark Andrews wrote: It's already there. If you want the ports as of FreeBSD 4.x EOL then the tag is RELEASE_4_EOL. If you want ports as of FreeBSD 9.0 then the tag is RELEASE_9_9_0. I did not know this. Do you have a link for this? I never read about it. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvs-tags.html If you wander around in http://www.freebsd.org/cgi/cvsweb.cgi/ you can see all the possible tags. Erich -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You NOT Using FreeBSD?
In message 2156532.vx6shro...@x220.ovitrap.com, Erich writes: Hi, On 03 June 2012 AM 9:15:14 Chris Rees wrote: On Jun 3, 2012 5:26 AM, Erich erichfreebsdl...@ovitrap.com wrote: Hi, On 02 June 2012 PM 2:56:01 Chris Nehren wrote: On Sat, Jun 02, 2012 at 14:11:06 -0400 , Paul Mather wrote: I'm not sure what the solution is for the end user. I know I get somewhat leery of updating my ports if I see a large number of change s coming via portsnap (like the 4000+ that accompanied the recent libpn g upgrade) and there is nothing new in UPDATING (which, happily wasn't the case with the libpng upgrade). Usually, I wait a while for the dust to clear and an UPDATING entry potentially to appear. If you're concerned about things breaking, don't follow the bleeding edge. This seems to be common sense. is there a second version of the ports tree available? What is the response of the list if you want to install a new package with you old ports tree? The response is Don't ask for support if you do that, I'm afraid. No major OS I can think of allows you to mix and match like that (though I could be wrong). it is new to me that Microsoft asks for a Windows update when a new Office ve rsion appears at the scene. No. It just silently does the OS update by installing new sets of libraries if required. When we install our software on a Windows machine we update the OS by installing the lastest C runtime libraries. We use Microsoft's installer but we do it. We also ship a private copy of the OpenSSL and libxml libraries we use. Microsoft also does not ask to update all other applications before the lates t Office can be installed. And you don't have to do that for FreeBSD if you don't want to. For each application you have you can put all the dependancies in its own tree. Apple does this for MacOS. The ports system defaults are to use a common build/runtime tree but at the cost of a little more disk space each major application could have its own build/runtime tree. This is a tradeoff. Most of the time having a shared set of libraries is a win, but just occasionally, it is a big pain. I've got a system where the X server is running a completely different set of libraries compared to the X applications. I just couldn't get the new server to work. I just took all the old server package and all its dependencies and installed it in a new location. This has a bit more that what is actually requires as I don't need all the header files but it works. For tools that are critical I would suggest building a seperate build / runtime tree. Disk space is relatively cheap. One thing that could help is splitting library packages into runtime / buildtime sub packages. That way you can reduce the foot print for a runtime install. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You NOT Using FreeBSD?
In message 7199276.kar7u8d...@x220.ovitrap.com, Erich writes: Hi, On 03 June 2012 PM 3:19:14 Doug Barton wrote: On 06/03/2012 05:43, Erich wrote: it is new to me that Microsoft asks for a Windows update when a new Office version appears at the scene. Actually it's very common for Windows applications to specify a minimum OS service pack level. To stretch the analogy a bit, you're also not going to find any modern Windows application that will run on Windows 98, for example. can you still install the ports tree and its applications on a FreeBSD 4.4? The ports system was deliberately broken once support for FreeBSD 4.x was dropped. You need a more up-to-date make than that which ships with FreeBSD 4.x and some other tools to be upgraded all of which were in FreeBSD 5.x. If someone had added a compatible make to ports and a couple of other tools used by the ports sub-system itself, those that wanted to continue using FreeBSD 4.x with ports could of. Instead the whole ports framework was updated to use incompatible Makefiles and tools without providing the necessary tools. It's not like make from FreeBSD 5.x or even FreeBSD 8.x doesn't compile on FreeBSD 4.x. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Installworld and /usr/include/*.h modification times
In message ca+7wwsewnfre8xz3h5huhww78yaxv7dkmyaivzamoy4kuz1...@mail.gmail.com , Kimmo Paasiala writes: On Fri, Jun 1, 2012 at 8:45 PM, Lowell Gilbert freebsd-stable-lo...@be-well.ilk.org wrote: Kimmo Paasiala kpaas...@gmail.com writes: Why are /usr/include files installed with install -C during make installworld =C2=A0when almost everything else is installed without the= -C flag? This makes it harder to track which files were actually installed during the last make installworld. One can easily find obsolete files =C2=A0(that are not covered with make delete-old(-libs)) with find -x / -type f -mtime +suitable_time but this doesn't work for /usr/include files because the modification times are not bumped on make installworld. make uses timestamps to determine whether to trigger a rule. Changing timestamps on source files without changing the contents is a bad idea. Yes, I'm aware of how make uses timestamps for figuring out out of date targets. However I would argue that after updating world with make installworld (which is done in single user mode there for requiring at least one reboot) you should start any compilations from scratch. The ports system does this by default and cleans up any previous work files before new compilation. I just don't see where bumping of mtimes for those files would have that great impact, does anyone? You obviously havn't had to deal with multi-day builds and also having to repair the OS. Preserving timestamps preserves re-startability. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Reject Action For SPF
In message a5bf45cb6468286ec3048a82a4e12243.squir...@mail.digital-infotech.net , Prabhpal S. Mavi writes: Why would you want to reject mail from legitimite senders that do not have SPF records published? Glen Dear Glen. B Thanks for your response, We want to implement this no our backup MX server. i trust this explains the reason. i know SPF is not spam prevention mechanize. Can you tell me how to set reject action? Fix your backup server to have the data required to perform the filtering. Don't force the rest of the world to waste cycles and bandwidth attempting to send email to a backup MX that you have advertised. If you can't do it correctly, DO NOT DO IT. Prabh S. Mavi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: UDP Packet reassembly
In message 4e345767.5070...@earthlink.net, Stephen Clark writes: Hello List, Didn't see this show up in the mailing list so I am resending. Could someone enlighten me as to when FreeBSD 6.3 does UDP packet reassembly? I am having a problem where I am getting a fragmented udp packet (2 pieces) everthing is fine if I get the first frag first. but if the second frag comes first then b oth fragments get dropped. I am using ipfilter and a bimap to redirect these packets to a host inside of the FreeBSD box, so I suspicion it is ipfilter causing the drops. I know, I know 6.3 is ancient history, but any insight would be appreciated. Know issue, http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/82806 Thank, Steve -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RELEASE_6 - RELEASE_8
I was trying to upgrade a machine from RELEASE_6 (latest) to RELEASE_8 (latest) via source. I was unable to get make buildworld to complete. There were two problems sets of problems. libelf and sys headers were not available to some of the solaris derived parts. include_next's failed. Adding extra -I's to the Makefiles allowed these parts to complete. The first missing header was sys/elf.h so that should help locate the correct Makefile. Linking then failed due to __stack_chk_fail_local not being found. i386 build. Sorry this report is not more complete as I blew away the tree and restarted on RELEASE_7 as a stepping stone to RELEASE_8. RELEASE_7 latest will at least compile. However it will only run in safe mode as it dies in ar5212Detach with a kernel fault. I suspect this will also be a problem for RELEASE_8. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELEASE_6 - RELEASE_8
In message 4d46119f.5060...@sentex.net, Mike Tancsa writes: On 1/30/2011 6:45 PM, Mark Andrews wrote: I was trying to upgrade a machine from RELEASE_6 (latest) to RELEASE_8 (latest) via source. I was unable to get make buildworld to complete. Strange, I have done a number of machines going from RELENG_6, RELENG_7 and then RELENG_8 without too much issue. The ports can be a bit problematic, but of the half dozen or so I have done, it hasnt been an issue. Were you using a custom kernel, or GENERIC as defined from each of the branches ? It's the double release jump that doesn't work. Looking at 7.x the headers needed are installed in /usr/include. Similarly 7.x's gcc has the symbol but doesn't turn on the compiler flags which use it. Basically RELENG_8 is not completely building against itself. Trying to go from 6.x to 8.x is showing some of places where the new OS doesn't build against itself. This was with GENERIC for all builds and almost no ports installed. ---Mike -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELEASE_6 - RELEASE_8
Mark Andrews writes:
In message 4d46119f.5060...@sentex.net, Mike Tancsa writes:
On 1/30/2011 6:45 PM, Mark Andrews wrote:
I was trying to upgrade a machine from RELEASE_6 (latest)
to RELEASE_8 (latest) via source. I was unable to get
make buildworld to complete.
Strange, I have done a number of machines going from RELENG_6, RELENG_7
and then RELENG_8 without too much issue. The ports can be a bit
problematic, but of the half dozen or so I have done, it hasnt been an
issue. Were you using a custom kernel, or GENERIC as defined from each
of the branches ?
It's the double release jump that doesn't work. Looking at 7.x the
headers needed are installed in /usr/include. Similarly 7.x's gcc
has the symbol but doesn't turn on the compiler flags which use it.
Basically RELENG_8 is not completely building against itself. Trying
to go from 6.x to 8.x is showing some of places where the new OS
doesn't build against itself.
This was with GENERIC for all builds and almost no ports installed.
The following Makefiles needed to be modified to add
-I${.CURDIR}/../../../lib/libelf and/or -I${.CURDIR}/../../../sys.
/usr/release8/src/cddl/usr.bin/sgsmsg/Makefile lib/libelf
/usr/release8/src/cddl/lib/libctf/Makefile lib/libelf sys
/usr/release8/src/cddl/usr.bin/ctfconvert/Makefile lib/libelf sys
/usr/release8/src/cddl/usr.bin/ctfmerge/Makefile sys
e.g.
CFLAGS+=-I${.CURDIR}/../../../sys/cddl/compat/opensolaris \
-I${.CURDIR}/../../../cddl/compat/opensolaris/include \
-I${.CURDIR}/../../../lib/libelf \
-I${.CURDIR}/../../../sys \
-I${OPENSOLARIS_USR_DISTDIR} \
-I${OPENSOLARIS_SYS_DISTDIR} \
-I${OPENSOLARIS_USR_DISTDIR}/head \
-I${OPENSOLARIS_USR_DISTDIR}/tools/ctf/common \
-I${OPENSOLARIS_USR_DISTDIR}/tools/ctf/cvt \
-I${OPENSOLARIS_SYS_DISTDIR}/uts/common
make make is also needed for 6.x - 8.x so that should be
added to UPDATING.
The build will then run until stopping in libexec/atrun with
/usr/release8/usr/release8/src/tmp/usr/lib/libpam.so: undefined reference to
`__stack_chk_fail_local'
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ntpd fails on boot
In message 20101218220244.ga19...@icarus.home.lan, Jeremy Chadwick writes: On Sat, Dec 18, 2010 at 11:37:21AM -0700, Dan Allen wrote: On 14 Dec 2010, at 5:47 PM, Jeremy Chadwick wrote: Anyway, many people are using the below with success. Sorry to say that netwait did NOT in the end fix the problem. I however discovered that if I put synchronous_dhclient=YES into my /etc/rc.conf file, that over many days reboots now has been delivering reliable networking such that ntpd always works. Thanks again to everyone for their help. For DHCP-based clients, yeah, netwait itself isn't sufficient; you'd need to use synchronous_dhclient as you discovered. synchronous_dhclient will accomplish the same thing as netwait for DHCP-based clients. Explanation: dhclient will sit and wait until DHCP is fully negotiated before continuing on with remaining rc scripts. The negotiation involves packets going back/forth between the client and server on UDP ports 67 and 68, which obvious acts as a validator that traffic is flowing across the interface. I'll add a comment to the top of the netwait script noting that it should be used for environments where the system is not using DHCP (configured static IPs in rc.conf), and mention for DHCP-based clients to use synchronous_dhclient instead. My solution was to start/re-start ntp using /etc/dhclient-exit-hooks whenever the IP address changed. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Enabling DNSSEC (Was: Re: RFC: Upgrade BIND version in RELENG_7 to BIND 9.6.x)
In message 4d0d408a.2020...@freebsd.org, Doug Barton writes: On 12/18/2010 09:16, Garrett Wollman wrote: In article4d0c49a2.4000...@freebsd.org, do...@freebsd.org writes: In order to avoid repeating the scenario where we have a version of BIND in the base that is not supported by the vendor I am proposing that we upgrade to BIND 9.6-ESV in FreeBSD RELENG_7. +1 All users are going to want working DNSsec soon, if they don't already, and that requires 9.6. (In fact, we should start shipping with DNSsec enabled by default and the root key pre-configured, if we aren't already doing so.) I'm not planning to do that in the base for a couple of reasons. The primary one being that the way BIND 9.6 handles the root key it would have to be manually re-configured when the root key changes. When that happens (not IF, it will happen someday) users who have the old configuration will no longer be able to validate. The other reason I don't want to do it in the base is that one open source OS vendor has already been burned by doing something similar, and I don't want to repeat that mistake. They also failed to put into place procedures to track the trust anchors as they change. OS vendors are in a much better place to do this than nameserver vendors. What I do plan to do (and hopefully before the upcoming release) is to make ports for BIND 9.6 and 9.7+ methods of handling DNSSEC so that users can enable and disable it easily, have a very easy way of being notified of changes, doing the updates, etc. It's also worth pointing out that BIND 9.7 and up support RFC 5011 rollover of the root key, which ICANN is going to perform, which means that people with old root keys in their configurations will be much more resilient. There is still a boot stap issue to be addressed. BIND 9.6 and BIND 9.7 has /etc/bind.keys which needs to be updated as the keys referenced there change. This is just a reference file in BIND 9.6. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /sbin/reboot
In message aanlktind3uzu6o-gf5j1b7cxp7dr1+jqvzbi9vjym...@mail.gmail.com, Adam Vande More writes: Is there a reason /sbin/reboot isn't assigned to the operator group or is this an oversight? Why would you want it to be? One really shouldn't be running /sbin/reboot directly as part of normal operations. shutdown does a graceful reboot if and when operators need to perform reboot. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /sbin/reboot
In message aanlktikggsyrlnds6oihw2u3syjezrrqwdsa9z4t7...@mail.gmail.com, Adam Vande More writes: On Fri, Dec 10, 2010 at 12:03 AM, Kevin Oberman ober...@es.net wrote: Unlike reboot, shutdown attempts to cleanly stop all processes. Things like databases can be badly damaged by a reboot. Other processes save state when stopped and that is lost with a reboot. For the correct order, shutdown -r calls reboot which calls init which calls rc.shutdown. Doing a shutdown -r is the same as a reboot without the warning to logged in users and shutdown handles the logging instead of reboot. Also, halt/reboot have options like -n and -q which can disrupt things worse than an unintended clean reboot. shutdown also give operator more possibilities than a clean shutdown some which could be very bad. -- Adam Vande More When you have administered multi-user systems you learn to do things gracefully unless you actually need to do things abbruptly. The operator group is for tape operators to be able shut the system down to perform backups. Telling people that the system is going down allows them to save work. You don't want tape operators to just bring the system down without notice if it can be avoided. Not giving the operator a command which will shut the system down without notice prevents this. Even shutdown -r now informs users that the system is going away and has not just crashed. With single user systems this isn't such a issue. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: BIND9 built w/--disable-ipv6 on 8.1-STABLE
There is way too much misinformation here. named probes the kernel to work out if it supports IPv6 or not. named -4 turns off IPv6 so there is no need to disable it at compile time. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: wpa_supplicant does not create pidfile
In message 4c85e638.4070...@bsdforen.de, Dominic Fandrey writes: On 07/09/2010 09:09, Bernhard Schmidt wrote: On Tuesday, September 07, 2010 09:01:18 Dominic Fandrey wrote: On 07/09/2010 08:50, Bernhard Schmidt wrote: On Friday, August 27, 2010 09:42:30 Bernhard Schmidt wrote: On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey kamik...@bsdforen.de wrote: On 27/08/2010 09:28, Bernhard Schmidt wrote: On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey kamik...@bsdforen.de wrote: wpa_supplicant doesn't create the pidfile if the target directory does not exist. Because /var/run is wiped with every boot I added the following line to my rc.local to workaround this issue: /bin/mkdir -p /var/run/wpa_supplicant I'm running RELENG_8. How about this? Index: etc/mtree/BSD.var.dist === --- etc/mtree/BSD.var.dist.(revision 211568) +++ etc/mtree/BSD.var.dist.(working copy) @@ -64,6 +64,8 @@ .. ppp gname=network mode=0770 .. +wpa_supplicant +.. .. rwhogname=daemon mode=0775 .. Is the mtree built every time the system boots? Because my /var/run is a tmpfs. And even if it wasn't, I think it's wiped every boot any way. Not build but, according to /etc/rc.d/var mtree is run on every boot. I actually tried that and it works just fine. Did you have a chance to try this? Given positive feedback I'd like to commit it. No, doesn't work. The named and ppp directories also don't exist. Sorry about the delay. Ok, thanks. Is it only /var/run/* that is wiped for you, or /var/* itself? I just check ed rc.d/var and it looks like this: if [ -d /var/run -a -d /var/db -a -d /var/empty ] ; then true elif [ -x /usr/sbin/mtree ] ; then populate_var So.. if var/run does exist, populate_var isn't run. Only /var/run and /var/log are tmpfs (notebook, reduce HD access to allow HD spindown). I wouldn't wipe my /var/db every boot. Then /var/run must exist as it is a mount point. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: cname replace in mail address? [off-topic] (Re: Attn Ronald Klop)
In message op.vh27cqoy852...@212-123-145-58.ip.telfort.nl, Ronald Klop writ es: offtopic, but why do some mailers replace a CNAME in a mail-address? Because it used to be manditory to do so. If you don't want it to be done use a MX record. klop.yi.org MX 0 thuis.klop.ws If you need klop.yi.org to have a address record then give it one. klop.yi.org A 212.123.145.58 Mark r...@sheeva2:/var/vmail# host klop.yi.org klop.yi.org CNAME thuis.klop.ws thuis.klop.ws A 212.123.145.58 It is not the first time that I'm bitten by this, but I never understood = =20 it. Ronald. On Tue, 24 Aug 2010 22:05:46 +0200, Andriy Gapon a...@icyb.net.ua wrote: Ronald, your email address bounces, that's inconvenient. Original Message Subject: Returned mail: Service unavailable Date: Tue, 24 Aug 2010 23:03:33 +0300 (EEST) From: Mail Delivery Subsystem mailer-dae...@citadel.icyb.net.ua To: a...@icyb.net.ua The original message was received at Tue, 24 Aug 2010 23:03:27 +0300 =20 (EEST) from porto-e.starpoint.kiev.ua [212.40.38.100] - The following addresses had permanent fatal errors - ronald-freeb...@thuis.klop.ws - Transcript of session follows - ... while talking to thuis.klop.ws.: RCPT To:ronald-freeb...@thuis.klop.ws 554 5.7.1 ronald-freeb...@thuis.klop.ws: Relay access denied 554 ronald-freeb...@thuis.klop.ws... Service unavailable ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Loader, MBR and the boot process
In message cf9b1ee01001240759j2476cf3es2babd8b32a90f...@mail.gmail.com, Dan N
aumov writes:
On Sun, Jan 24, 2010 at 5:29 PM, John j...@starfire.mn.org wrote:
On Fri, Jan 22, 2010 at 07:02:53AM +0200, Dan Naumov wrote:
On Fri, Jan 22, 2010 at 6:49 AM, Dan Naumov dan.nau...@gmail.com wrote=
:
On Fri, Jan 22, 2010 at 6:12 AM, Thomas K. f...@gothschlampen.com wro=
te:
On Fri, Jan 22, 2010 at 05:57:23AM +0200, Dan Naumov wrote:
Hi,
I recently found a nifty FreeBSD ZFS root installation script and
been reworking it a bit to suit my needs better, including changing =
it
from GPT to MBR partitioning. However, I was stumped, even though I
had done everything right (or so I thought), the system would get
stuck at Loader and refuse to go anywhere. After trying over a dozen
probably this line is the cause:
dd if=3D/mnt2/boot/zfsboot of=3D/dev/${TARGETDISK}s1a skip=3D1 seek=
=3D1024
Unless by swap first you meant the on-disk location, and not the
partition letter. If swap is partition a, you're writing the loader
into swapspace.
Regards,
Thomas
At first you made me feel silly, but then I decided to double-check, I
uncommented the swap line in the partitioning part again, ensured I
was writing the bootloader to ${TARGETDISK}s1b and ran the script.
Same problem, hangs at loader. Again, if I comment out the swap,
giving the entire slice to ZFS and then write the bootloader to
${TARGETDISK}s1a, run the script, everything works.
I have also just tested creating 2 slices, like this:
gpart create -s mbr ${TARGETDISK}
gpart add -s 3G -t freebsd ${TARGETDISK}
gpart create -s BSD ${TARGETDISK}s1
gpart add -t freebsd-swap ${TARGETDISK}s1
gpart add -t freebsd ${TARGETDISK}
gpart create -s BSD ${TARGETDISK}s2
gpart add -t freebsd-zfs ${TARGETDISK}s2
gpart set -a active -i 2 ${TARGETDISK}
gpart bootcode -b /mnt2/boot/boot0 ${TARGETDISK}
and later:
dd if=3D/mnt2/boot/zfsboot of=3D/dev/${TARGETDISK}s2 count=3D1
dd if=3D/mnt2/boot/zfsboot of=3D/dev/${TARGETDISK}s2a skip=3D1 seek=3D=
1024
Putting the swap into it's own slice and then putting FreeBSD into
it's own slice worked fine. So why the hell can't they both coexist in
1 slice if the swap comes first?
I know what the answer to this USED to be, but I don't know if it is
still true (obviously, I think so, I or wouldn't waste your time).
The filesystem code is all carefully written to avoid the very
first few sector of the partition. =A0That's because the partition
table is there for the first filesystem of the slice (or disk).
That's a tiny amout of space wasted, because it's also skipped on
all the other filesystems even though there's not actually anything
there, but it was a small inefficency, even in the 70's.
Swap does not behave that way. =A0SWAP will begin right at the slice
boundry, with 0 offset. =A0As long as it's not the first partition, no
harm, no foul. =A0If it IS the first partition, you just nuked your parti=
tion
table. =A0As long as SWAP owns the slice, again, no harm, no foul, but
if there were filesystems BEHIND it, you just lost 'em.
That's the way it always used to be, and I think it still is. =A0SWAP can
only be first if it is the ONLY thing using that slice (disk), otherwise,
you need a filesystem first to protect the partition table.
--
John Lind
j...@starfire.mn.org
This explanation does sound logical, but holy crap, if this is the
case, you'd think there would be bells, whistles and huge red label
warnings in EVERY FreeBSD installation / partitioning guide out there
warning people to not put swap first (unless given a dedicated slice)
under any circumstances. The warnings were nowhere to be seen and lots
of pointy hair first greyed and were then lost during the process of
me trying to figure out why my system would install but wouldn't boot.
From man bsdlabel.
offset The offset of the start of the partition from the beginning of
the drive in sectors, or * to have bsdlabel calculate the correct
offset to use (the end of the previous partition plus one, ignor-
ing partition `c'. For partition `c', * will be interpreted as
an offset of 0. The first partition should start at offset 16,
because the first 16 sectors are reserved for metadata.
- Sincerely,
Dan Naumov
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any
Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop
Report it using send-pr. That way the problem will make its way into the
bug tracking system.
In message 86aayc7z4g@zhuzha.ua1, Mikolaj Golub writes:
Hi,
I have problems with compiling our application under 8.0.
It fails due to these definitions in pthread.h that look like a typo or
incorrectly applied patch:
170 #define pthread_cleanup_push(cleanup_routine, cleanup_arg)
\
171 {
\
172 struct _pthread_cleanup_info
__cleanup_info__;
\
173 __pthread_cleanup_push_imp(cleanup_routine,
clean
up_arg,\
174 __cleanup_info__);
\
175 {
176
177 #define pthread_cleanup_pop(execute)
\
178 }
\
179 __pthread_cleanup_pop_imp(execute);
\
180 }
This patch fixes the problem for me:
--- pthread.h.orig2009-11-24 16:44:13.0 +0200
+++ pthread.h 2009-11-24 16:44:45.0 +0200
@@ -172,10 +172,10 @@
struct _pthread_cleanup_info __cleanup_info__;
\
__pthread_cleanup_push_imp(cleanup_routine,
cleanup_arg,\
__cleanup_info__);
\
- {
+ }
#definepthread_cleanup_pop(execute)
\
- }
\
+ { \
__pthread_cleanup_pop_imp(execute);
\
}
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop
+MBN1Mb4h4UwCgxIIHVqHBqU9wPIQKiOWf9g2z r94AoOiN4CE6Eig6AlJ1IuHFo9Hk7Pvf =FjUi -END PGP SIGNATURE- --i616tqyc3hrkKsk2-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop
In message pine.gso.4.64.0911241718490.5...@sea.ntplx.net, Daniel Eischen wri
tes:
On Wed, 25 Nov 2009, Mark Andrews wrote:
In message 20091124153422.gt2...@deviant.kiev.zoral.com.ua, Kostik Belous
ov write
s:
--i616tqyc3hrkKsk2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Nov 24, 2009 at 05:18:29PM +0200, Mikolaj Golub wrote:
pthread_cleanup_push/pop are supposed to be used from the common
lexical scope. Citation from SUSv4:
These functions may be implemented as macros. The application shall
ensure that they appear as statements, and in pairs within the same
lexical scope (that is, the pthread_cleanup_push() macro may be
thought to expand to a token list whose first token is '{' with
pthread_cleanup_pop() expanding to a token list whose last token is the
corresponding '}' ).
Your change is wrong.
Basically, the code should do
pthread_cleanup_push(some_func, arh);
something ...
pthread_cleanup_pop(1);
(1 denotes that some_func should be called).
The problem is that that expands to C code that can only be used
with newer C compilers. This expansion should be usable with all
C compilers.
#define pthread_cleanup_push(cleanup_routine, cleanup_arg)
\
{ \
struct _pthread_cleanup_info __cleanup_info__; \
__pthread_cleanup_push_imp(cleanup_routine, cleanup
_arg,\
__cleanup_info__)
#define pthread_cleanup_pop(execute)
\
__pthread_cleanup_pop_imp(execute);\
} ((void)0)
Hmm, agreed. But note that Solaris 10 does it this way:
#define pthread_cleanup_push(routine, args) { \
_cleanup_t _cleanup_info; \
__pthread_cleanup_push((_Voidfp)(routine), (void *)(args), \
(caddr_t)_getfp(), _cleanup_info);
#define pthread_cleanup_pop(ex) \
__pthread_cleanup_pop(ex, _cleanup_info); \
}
Writing portable macros that don't generate compiler warnings is fun. :-)
Tricks like do { body } while (0) and { body } ((void)0) absorb
the pesky semi-colon.
--
DE
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [solved] Re: Re: Re: diskless - NFS root mount problem
In message 4b01c4df.4040...@freebsd.org, Doug Barton writes: Mario Pavlov wrote: Hi, it turned out I was stupid enough to misconfigure the kernel...I forgot that I had left the IPFIREWALL options turned on You're not a real sysadmin until you've firewalled yourself out of at least one mission-critical system. Bonus points if it has no out-of-band control plane. Further bonus points if it is more than 100 miles away, and you are the one who has to drive to the data center. Triple bonus points if it is +20 hours of flight time away. Home data center and angry wife w/o Internet access. Yes I managed to stuff up a home machine while in Ireland. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Not getting an IPv6 in a jail
In message 20090902160440.ga28...@sd-13813.dedibox.fr, FLEURIOT Damien writes
:
On Tue, Sep 01, 2009 at 08:15:24PM + or thereabouts, Bjoern A. Zeeb wrote
:
On Tue, 1 Sep 2009, Major Domo wrote:
Hi,
Apologies if this has been discussed already but I searched the web
and the mailing lists and haven't found hints on my problem.
I've got a jail, I assign it a set of IP addresses, and it just won't
take the IP6 I give it.
Uname:
FreeBSD 7.2-STABLE
jail_ns_ip=192.168.0.252,fe80::c0a8:fc
jls -v:
JID Hostname Path
Name State
CPUSetID
IP Address(es)
23 [snip] /var/jail/ns
ALIVE
2
192.168.0.252
fe80::c0a8:fc
ifconfig lo252 from the host:
lo252: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384
inet 192.168.0.252 netmask 0x
inet6 fe80::c0a8:fc%lo252 prefixlen 128 scopeid 0x5
ifconfig from the jail:
re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=389bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_
UCAST,WOL_MCAST,WOL_MAGIC
ether 00:e0:f4:19:e9:d2
media: Ethernet autoselect (100baseTX full-duplex)
status: active
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384
pflog0: flags=141UP,RUNNING,PROMISC metric 0 mtu 33204
lo252: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384
inet 192.168.0.252 netmask 0x
This is a rather special case. For link-local addresses you have to
give the scope as well but it won't take the scope with the %lo252
notation but only in the KAME in-kernel syntax I would assume.
Can you try:
jail_ns_ip=192.168.0.252,fe80:5::c0a8:fc
Note the added 5 in the second group of hex digits. That five is the
interface index. I took it from the scopeid 0x5. In case your
interface index changes you will need to adjust the address.
I cannot say if it'll work but it would be worth a try.
/bz
--
Bjoern A. Zeeb What was I talking about and who are you again?
Hi list, Bjoern, John,
I confirm it is now working with the following line in /etc/rc.conf:
jail_ns_ip=192.168.0.252,fec0:5::df:252
along with redirections in /etc/pf.conf:
rdr pass log on $ext_if inet proto {tcp,udp} to $ext_if port 53 -
$lo252_if port 53
rdr pass log on $ext_if inet6 proto {tcp,udp} to $ext_if port 53 -
$lo252_if port 53
Notice the use of both the interface's index and a site-local ip6
address instead of the old fe80 as suggested.
BIND's now happily running in its jail and responding to public
queries.
Perhaps a small addition to the jails entry in the Handbook to
advise people about the use of IP6 addresses on loopback interfaces
would be warranted ?
I realize how lousy it is to NAT IP6 but my host assigns only 1
IP6 address per server.
Then complain. There is no reason to be miserly with IPv6 addresses.
Thanks for the help !
Regards
--
Damien
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Shell execution ( [was] Re: Value of $? lost in the beginning of a function.)
In message 4ad871310907191717g1ed90be7y92250f2addc38...@mail.gmail.com, Glen Barber writes: Possibly off-topic... 2009/7/19 Glen Barber glen.j.bar...@gmail.com: 2009/7/19 Romain Tarti=E8re rom...@blogreen.org: Hi Glen, On Sun, Jul 19, 2009 at 04:32:28PM -0400, Glen Barber wrote: % sh foo.sh % zsh foo.sh % bash foo.sh What happens if you replace '#!/bin/sh' with '#!/usr/local/bin/zsh' ? This is not related to my problem since I am not running the script using ./foo.sh but directly using the proper shell. =A0sh just behaves differently, that looks odd so I would like to know if it is a bug in sh or if there is no specification for this and the behaviour depends of the implementation of each shell, in which case I have to tweak the script I am porting to avoid this construct (passing $? as an argument for example). Romain My understanding was this: If you specify 'sh foo.sh' at the shell, the script will be run in a /bin/sh shell, _unless_ you override the shell _in_ the script. Ie, 'sh foo.sh' containing '#!/bin/sh' being redundant, but 'zsh foo.sh' containing '#!/bin/sh' would execute using zsh. I meant to say in the last line: '#!/bin/sh' would override the 'zsh' shel= l. Can someone enlighten me if I am wrong about this? --=20 Glen Barber ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org #! is used to define the interpretor when the file is exec'd. perl, AFAIK, is the only interpretor that will look at what is after the #! and modify it's behaviour. All other a interpretors (shells) treat #! as a comment. Some shells used to examine the executable about to be called and looked for #! and invoke the correct interpretor. This was how #! was supported before kernels has support for #!. It was all done in userland. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: rndc: connect failed: 127.0.0.1#953: connection refused
In message a035ff0bce7803787bd454078722a...@mail.isot.com, Squirrel writes:
My BIND9.6.0 on FreeBSD 6.2 works fine when I manually start with:
r...@ns2# named -4 -S 1024 -c /etc/namedb/named.conf
But it won't start on boot and no error messages or log. And it won't start
using rndc, it cause error message. Why does the error shows port 953 when I
specified for port 53 in the config?
Port 53 is for DNS.
Port 952 is the default port for RNDC.
rndc: connect failed: 127.0.0.1#953: connection refused
Run named -4 -S 1024 -c /etc/namedb/named.conf -g and read the
messages.
Below are parts of my configs:
/etc/rc.conf:
named_enable=YES
named_flags=-4 -S 1024 -c /etc/namedb/named.conf
/etc/rndc.key:
key rndc-key {
algorithm hmac-md5;
secret y9eca/WZydNfi...;
};
/etc/namedb/rndc.conf:
include /etc/namedb/rndc.key;
options {
default-server localhost;
default-key rndc-key;
};
server localhost {
key rndc-key;
};
...
/etc/namedb/named.conf:
include /etc/namedb/rndc.key;
acl internals {
aa.bb.cc.0/20;
192.168.1.0/24;
127.0.0.0/8;
};
controls {
inet 127.0.0.1 port 53 allow { 127.0.0.1; } keys { rndc-key; };
};
options {
pid-file /var/run/named.pid;
directory /etc/namedb;
statistics-file /var/log/named/named.stats;
dump-file /var/log/named/named.dump;
zone-statistics yes;
allow-query { 127.0.0.1; 66.187.80.0/20; };
};
logging {
category default { simple_log; };
channel simple_log {
file /var/log/named/named.log versions 5 size 20m;
severity warning;
print-time yes;
print-category yes;
print-severity yes;
};
...
---
PCShare.Com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
http://www.freebsd.org/doc/handbook/desktop-browsers.html
Can the instructions for adding a java pluging please be updated to something that works as what's there doesn't work for Firefox 3. javavmwrapper-2.3.2 is installed. % ls -l /usr/local/lib/browser_plugins/ total 0 lrwxr-xr-x 1 root wheel 67 Feb 8 10:38 libjavaplugin_oji.so - /usr/local/diablo-jdk1.6.0/jre/plugin/i386/ns7/libjavaplugin_oji.so % ls -lL /usr/local/lib/browser_plugins/ total 188 -rwxr-xr-x 1 root wheel 191059 Jun 18 2008 libjavaplugin_oji.so % Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Looping: Re: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address
Can the freebsd-stable subscriber at exchange.physicalsegment.com please stop looping email. If you want to re-inject email DO NOT use the To: or Cc: lines to determine where to send the email to. It just creates email loops. Mark Received: from mail pickup service by exchange.physicalsegment.com with Microsoft SMTPSVC; Tue, 27 Jan 2009 21:33:34 + Received: from mx2.freebsd.org ([69.147.83.53]) by tsplpt01.thespinney.local with Microsoft SMTPSVC(6.0.2600.5512); Sun, 25 Jan 2009 15:08:47 + In message 497bc46e.8020...@freebsd.org, Doug Barton writes: Mark Andrews wrote: In message 497bbe2c.5060...@freebsd.org, Doug Barton writes: Mark Andrews wrote: In message 497b9ff4.30...@freebsd.org, Doug Barton writes: Any time you are using NFS you should maintain the addresses of the critical hosts in /etc/hosts. Yes, I realize that's anachronistic (especially for a DNS guy) but it works. Obviously you should make sure to update them as needed. Or keep a local copy of the zone which contains them. I actually considered suggesting that option, but it's unclear to me whether or not named would answer at all, even for a local zone, given the situation described. named will always answer for local zones. b.t.w. BIND 9 primes when it attempts to recurse for the first time. Interesting, thanks! Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD-7.1STABLE w/BIND-9.4.3-P1 start problem
Remove query-source address * port 53; and fix your firewall. 2509. [bug] Specifying a fixed query source port was broken. [RT #19051] Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD-7.1STABLE w/BIND-9.4.3-P1 start problem followup
In message 006301c98046$392ee350$c7010...@engineer, Balgansuren Batsukh wri tes: Installed using pkd_add or ports BIND-9.6.0-P1 working fine. 1.But seems can't run under chroot well: -- Jan 27 13:54:08 ns named[36447]: starting BIND 9.6.0-P1 -c named.conf -t = /var/named -u bind Jan 27 13:54:08 ns named[36447]: built with '--localstatedir=3D/var' = '--disable-linux-caps' '--with-randomdev=3D/dev/random' = '--disable-openssl-version-check' '--without-openssl' = '--with-libxml2=3D/usr/local' '--with-idn=3D/usr/local' = '--with-libiconv=3D/usr/local' '--enable-threads' = '--prefix=3D/usr/local' '--mandir=3D/usr/local/man' = '--infodir=3D/usr/local/info/' '--build=3Di386-portbld-freebsd7.1' = 'build_alias=3Di386-portbld-freebsd7.1' 'CC=3Dcc' 'CFLAGS=3D-O2 = -fno-strict-aliasing -pipe' 'LDFLAGS=3D = -rpath=3D/usr/lib:/usr/local/lib' 'CXX=3Dc++' 'CXXFLAGS=3D-O2 = -fno-strict-aliasing -pipe' Jan 27 13:54:08 ns named[36447]: none:0: open: /usr/local/etc/rndc.key: = file not found Jan 27 13:54:08 ns named[36447]: couldn't add command channel = 127.0.0.1#953: file not found As root run rndc-confgen -a -t /var/named. Jan 27 13:54:08 ns named[36447]: the working directory is not writable Jan 27 13:54:08 ns named[36447]: running 2./etc/rc.conf --- named_enable=3DYES named_program=3D/usr/local/sbin/named # path to named, if you want a = different one. named_flags=3D-c named.conf named_uid=3Dbind# User to run named as named_chrootdir=3D/var/named# Chroot directory (or not to = auto-chroot it) named_chroot_autoupdate=3DYES # Automatically install/update = chrooted # components of named. See = /etc/rc.d/named. named_symlink_enable=3DYES # Symlink the chrooted pid file 3./etc/rc./named stop named not running? (check /var/run/named/pid). 4.ns# /usr/local/sbin/named -v BIND 9.6.0-P1 Any suggestion to fix some cosmetic problem? Balgaa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address
In message 497b9ff4.30...@freebsd.org, Doug Barton writes: Lev Serebryakov wrote: Hello, Freebsd-stable. BIND on my new router (7.1-STABLE, BIND 9.4.3-P1) shows bunch of errors on every start and doesn't answer on requests for 30-60 seconds after that. Errors are like this: It's not necessary or desirable to paste in so many examples of the same message. It's also not good to cross post the same message to multiple lists. Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib /bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured That message is fairly clear, the system has told named that it can talk to the outside world, but there isn't anything there for named to talk to. As you already pointed out in another message, the IP addresses are for the root name servers. The first thing named does when it starts up is to verify the information in the hints file. Main problem is, that mount_nfs failed on startup on this router because bind is not ready due to these errors and all system goes to single-user mode :( Any time you are using NFS you should maintain the addresses of the critical hosts in /etc/hosts. Yes, I realize that's anachronistic (especially for a DNS guy) but it works. Obviously you should make sure to update them as needed. Or keep a local copy of the zone which contains them. If you have a copy in /etc/hosts there should be procedures to keep /etc/hosts in sync with the DNS. Computer is Soekris net5501, with 6 network interfaces (vr0-vr3 on board, em0 and ath0 attached). Only vr0 and vr1 are used, but adding fake addresses to vr2 and vr3 doesn't help at all. Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect t o two providers. But previous installation (on faster hardware) doesn't show these errors at all! I've never used mpd myself, but you might want to try adding the following line to /usr/local/etc/rc.d/mpd and see if it helps: # BEFORE: named mpd should also be fixed as the error code being returned is not approprate. network unreachable is what should be returned. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address
In message 497bbe2c.5060...@freebsd.org, Doug Barton writes: Mark Andrews wrote: In message 497b9ff4.30...@freebsd.org, Doug Barton writes: Any time you are using NFS you should maintain the addresses of the critical hosts in /etc/hosts. Yes, I realize that's anachronistic (especially for a DNS guy) but it works. Obviously you should make sure to update them as needed. Or keep a local copy of the zone which contains them. I actually considered suggesting that option, but it's unclear to me whether or not named would answer at all, even for a local zone, given the situation described. named will always answer for local zones. b.t.w. BIND 9 primes when it attempts to recurse for the first time. Doug This .signature sanitized for your protection -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7.1 and BIND exploit
--==79D675BB9A887D4CB823== Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On July 23, 2008 10:46:43 AM +1000 Mark Andrews [EMAIL PROTECTED]=20 wrote: I just played around with it recently. It's not that easy to understand initially *and* the trust anchors thing is a royal PITA. Once you implement DNSSEC you *must* generate keys every 30 days. So, I thin k, if you're going to enable it by default, there needs to be a script in period ic that will do all the magic to change keys every 30 days. Maybe put vars in /etc/rc.conf to override the default key lengths and other portions of the commands that could change per installation. WRONG. You need to re-sign the zone an expire period before the signatures expire. You need to generate new keys periodically but no where near every 30 days. OK. I misspoke. I got the 30 days from Andrew Clegg's presentation and=20 confused keys with signatures. But still, you have to resign *every* zone = every 30 days. Signatures have lifespans =E2=80=9CBorn-on=E2=80=9D date =E2=80=93 1 hour prior to running dnssecsignzone Expiration date =E2=80=93 30 days after running dnssecsignzone Expired signatures lead to zones that will not validate! I followed Clegg's presentation to try out dnssec. Then there's this: Any time you modify a zone =E2=80=93 or at least every 30 days (minus TTL) you must re-run dnssecsignzone If you don't 1) Zone data will be stale 2) Zone data will be GONE So, for me, that's three zones I have to mess with every 30 days. Then=20 Clegg says the the ZSK keys should be changed every quarter and the KSK=20 keys every year. So I have to resign monthly, regen ZSK keys quarterly=20 and regen KSK keys annually, and I have to do this without breaking any of = my zones so that they stop resolving for periods long enough to clear out=20 caches. How is the average person supposed to understand this, much less do it=20 correctly? Don't misunderstand me, Mark, I'm all for security. But this=20 ain't easy, and the online information only confuses the issue. Firstly just re-sign weekly (pick a day of the week and keep to it). You have to be away multiple weeks for the zone to expire. BIND 9.6 will be able to automatically re-sign a dynamic zone. To roll a zone signing key. Add the new key at the weekly signing. Remove the old key the next week. This provides a one week overlap and as long as no TTL in the zone is larger than 1 week (enforced by lots of caches). To roll a key signing key. Add the key at a weekly signing. Wait for the DNSKEY RRset TTL to expire. Send the new DS/DLV records for the new keys to the parent/DLV operator. Once the updated parent / DLV operator has updated the DS/DLV RRset wait for the old TTL to expire. Remove the old key signing key at your discression. Normally you would do this at the next weekly signing. This proceedure requires one interaction with the parent/dlv operator during the rollover. Note this is not much different than what is required when changing a nameservers. Clegg also says this: When finished: 2 ZSK files (.key and .private) 2 KSK files (.key and .private) 2 zonefiles (unsigned and .signed) So, do I have to have two zone files or not? As someone who is trying to=20 understand this new technology, I have to tell you, the online=20 documentation isn't written for non dns-gurus. I'll be happy to sign my zones, but not until I understand how it works,=20 what the ramifications are and what my maintenance responsibilities are. Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
Le Wed 23/07/2008, Mark Andrews disait To roll a key signing key. Add the key at a weekly signing. Wait for the DNSKEY RRset TTL to expire. Send the new DS/DLV records for the new keys to the parent/DLV operator. Once the updated parent / DLV operator has updated the DS/DLV RRset wait for the old TTL to expire. Remove the old key signing key at your discression. Normally you would do this at the next weekly signing. This proceedure requires one interaction with the parent/dlv operator during the rollover. Note this is not much different than what is required when changing a nameservers. But changing nameserver is an exceptional operation. Nobody wants the burden of an exceptional operation to come back regularly. KSK changes should be approximately annual which is short enough not to forget but long enough to not be a burden. -- Erwan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
--On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton [EMAIL PROTECTED] wrote: Matthew Seaman wrote: Are there any plans to enable DNSSEC capability in the resolver built into FreeBSD? The server is already capable of it. I'm seriously considering enabling the define to make the CLI tools (dig/host/nslookup) capable as well (there is already an OPTION for this in ports). The problem is that _using_ DNSSEC requires configuration changes in named.conf, and more importantly, configuration of trust anchors (even fo r the command line stuff) since the root is not signed. It's not hard to do that with the DLV system that ISC has in place, and I would be willing to create a conf file that shows how to do that for users to include if they choose to. I am not comfortable enabling it by default (not yet anyway), it 's too big of a POLA issue. I just played around with it recently. It's not that easy to understand initially *and* the trust anchors thing is a royal PITA. Once you implement DNSSEC you *must* generate keys every 30 days. So, I thin k, if you're going to enable it by default, there needs to be a script in period ic that will do all the magic to change keys every 30 days. Maybe put vars in /etc/rc.conf to override the default key lengths and other portions of the commands that could change per installation. WRONG. You need to re-sign the zone an expire period before the signatures expire. You need to generate new keys periodically but no where near every 30 days. KSKs annually. This is what the TLD's are doing and that is a very conservative exposure period. In practice it could be multiple years between key rollovers. The reason it is done this frequently is so humans don't forget what they need to do. ZSKs are generally weaker than KSKs but again they don't need to be done monthly. If I were to implement it, I'd write a shell script to turn the keys over and cron it because doing it manually every 30 days ain't gonna happen. Too many ways to forget to do it. (I did the same for the root servers so that named. ca gets updated automagically every month.) But until root is signed, it's not worth it for those of us who don't have dedicated staff doing dns only. There are solutions to the root not being signed. If all the TLD were signed the trust anchor work load would not be too great to managed by hand. For those that want a single trust anchor solution there is DLV. Sign your zone. Add it to a DLV. Ask you parent to sign their zone. If you don't sign you parent has no insentive to sign. This can be driven bottom up. That is one of the reasons why DLV was invented to provide incentive for the parent zones to sign. Mark -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --enig5488BAD5E4511AF4D0C2864A Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Doug Barton wrote: Matthew Seaman wrote: =20 Are there any plans to enable DNSSEC capability in the resolver built = into FreeBSD? =20 The server is already capable of it. I'm seriously considering enabling= =20 the define to make the CLI tools (dig/host/nslookup) capable as well=20 (there is already an OPTION for this in ports). Forgive me for being obtuse. What I meant was the capability to enable c= hecking signatures on DNS RRs as a routine effect of getnameinfo() etc. by modifying resolver(3) routines or similar locally, without needing a DNSSEC enabled recursive resolver listed in resolv.conf? I've a feeling the answer is no, but I haven't been able to find anything definitive. Which I suppose simply means that if you're in the habit of, for example,= =20 taking your laptop into the coffee shop and getting on line there then yo= u=20 need to run your own instance of named on your laptop rather than blindly= =20 trusting whatever servers the coffee shop provides via their DHCP. Use a local (on machine) validating caching nameserver. The problem is that _using_ DNSSEC requires configuration changes in=20 named.conf, and more importantly, configuration of trust anchors (eve= n=20 for the command line stuff) since the root is not signed. It's not hard= =20 to do that with the DLV system that ISC has in place, and I would be=20 willing to create a conf file that shows how to do that for users to=20 include if they choose to. I am not comfortable enabling it by default = (not yet anyway), it's too big of a POLA issue. I sense a business opportunity in providing DLV there. I'm wondering why= the likes of Verisign (including Thawte and Geotrust), Comodo group and=20 GoDaddy aren't circling like vultures over a dead wildebeest. Perhaps th= ey=20 are. You only need one DLV. ISC is offering the service for free. Donations welcome as it does cost to run the service. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW --enig5488BAD5E4511AF4D0C2864A Content-Type: application/pgp-signature; name=signature.asc Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkiGKPIACgkQ8Mjk52CukIxbWACfTVCDPVViUJ0NTd5GLMMVU8bD xXkAniwbkPNqgVZYLi4a/5aQHYFxBHSo =T6Z8 -END PGP SIGNATURE- --enig5488BAD5E4511AF4D0C2864A-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
On Tue, Jul 22, 2008 at 05:52:42PM +0200, Oliver Fromme wrote: Brett Glass wrote: At 02:24 PM 7/21/2008, Kevin Oberman wrote: Don't forget that ANY server that caches data, including an end system running a caching only server is vulnerable. Actually, there is an exception to this. A forward only cache/resolver is only as vulnerable as its forwarder(s). This is a workaround for the vulnerability for folks who have systems that they cannot easily upgrade: point at a trusted forwarder that's patched. We're also looking at using dnscache from the djbdns package. I'm curious, is djbdns exploitable, too? Does it randomize the source ports of UDP queries? AFAIK Dan Bernstein first spelled out the fundamental problems with DNS response forgery in 2001. He implemented dnscache to randomize source ports and IDs from the beginning, via a cryptographic quality RNG. See for instance this page, much of it written in 2003: http://cr.yp.to/djbdns/forgery.html And the IETF was working on a solution well before that. One that addressed not only off path attacks but also addressed on path attacks. One that worked with kernels that only supported limited numbers of file desriptors. One that worked regardless on the number of concurrent outstanding queries. That solution is called DNSSEC. We looked at what Dan did and said it didn't go far enough and that it has implementation issues at high query rates that can't be solved just by throwing more cpu at the problem. The problems are inherent to how UDP works. He rubs a lot of people the wrong way, but I think he has usually proved to be right on security issues. Dan is often right. However a different, more encompassing, solution was choosen. I also think that modular design of security-sensitive tools is the way to go, with his DNS tools as with Postfix. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named.conf: query-source address
query-source is only ever used by recursive or stub resolvers -- instances of named that will go out and make queries on the net on your=20 behalf. Authoritative servers really don't need it. Actually authoritative servers make queries to work out where to send notify messages. While sending a notify to the wrong place is not that bad. It is good practice to see that authoritative servers are also fixed now rather than later. Servers have a habit of changing roles and when that happens not everyone will looks in options to see if query source is correct. Also at some point I'd like to be able to get rid of masters clauses or at least go from IP addresses to hostnames. The slave / stub zones would then have to go out and discover the ip address on the fly. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named.conf: query-source address
We do such on our authoritative nameservers. The options we use:
listen-on { 127.0.0.1; 72.20.106.4; };
query-source address 72.20.106.4;
transfer-source 72.20.106.4;
notify-source 72.20.106.4;
interface-interval 0;
use-alt-transfer-source no;
That's perfectly fine.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6to4 suddenly stopped working to 2001: addresses
I've got three installations of FreeBSD using 6to4 in three different physical locations, attached to three different ISPs. Sometime in the last few days all of them have stopped talking to IPv6 addesse which are not also 6to4. I can still talk to 2002: addresses, but not to 2001: addresses. This all worked fine a few days ago, and nothing has changed in the config of any of these machines. I can ping 192.88.99.1 under IPv4, so I should have a route to 2002:c390:806::, but traceroute6 to anything not in 2002: doesnt show any hops, and I cannot connect to any of these sites. You need to talk to the operators of the last hop before 192.88.99.1 in the traceroute. Can anyone shed any light on this ? It hardly seems likely that theres been some massive failure of 6to4 in the London area, but I can't see any reason why all of this would have suddenly stopped working. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 02:01:48PM -1000, Clifton Royston wrote: On Mon, May 19, 2008 at 03:14:08PM -0500, Dave Uhring wrote: The problem is that gcc is *not* finding the file in the directory referenced by the -I cflag. If I copy the header files to the directory where the error occurs the header file is found and used to compile the source file. This starts to narrow down the problem you're having a bit, I think. Given that this is different from the expected behavior and the behavior others are seeing, this sounds to me like either 1) the wrong compiler or version of the compiler is being found and used in place of the desired gcc instance, or 2) something in your shell or environment is somehow getting into the buildworld environment and causing make or the inner shell to misparse the commandline to gcc. The c compiler is the one shipped with 7.0 RELEASE. Except for the 3 new header files that I placed from cvsupped sources into /usr/include/sys the entire system is 7.0 RELEASE. Prior to beginning the build I deliberately set # export CFLAGS= This does NOT remove CFLAGS from the environment. env -i PATH=$PATH make ... will clear the enviornment and just add PATH. e.g. % env -i PATH=$PATH SHELL=$SHELL HOME=$HOME printenv PATH=/home/marka/gnu/bin:/home/marka/bin/mask:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin:/usr/X11R6/bin:/home/marka/bin:/usr/local/sbin SHELL=/bin/csh HOME=/home/marka % Nothing else in my environment would have affected the compiler. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote: # export CFLAGS= This does NOT remove CFLAGS from the environment. It does when you shell is bash. bash is broken. Empty environment variables have meaning. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote:
# export CFLAGS=
This does NOT remove CFLAGS from the environment.
It does when you shell is bash.
bash is broken. Empty environment variables have meaning.
Mark
And when tested does behave the way you describe.
Mark
drugs:9.5.x 13:30 {4371} % bash
[EMAIL PROTECTED] ~/cvs/9.5.x]$ printenv | grep FOO
[EMAIL PROTECTED] ~/cvs/9.5.x]$ FOO=ll
[EMAIL PROTECTED] ~/cvs/9.5.x]$ export FOO
[EMAIL PROTECTED] ~/cvs/9.5.x]$ printenv | grep FOO
FOO=ll
[EMAIL PROTECTED] ~/cvs/9.5.x]$ FOO=
[EMAIL PROTECTED] ~/cvs/9.5.x]$ export FOO
[EMAIL PROTECTED] ~/cvs/9.5.x]$ printenv | grep FOO
FOO=
[EMAIL PROTECTED] ~/cvs/9.5.x]$ env -i PATH=$PATH printenv | grep FOO
[EMAIL PROTECTED] ~/cvs/9.5.x]$
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INET6 -- and why I don't use it
On Thu, 06 Mar 2008 11:24:08 -0800 Kevin Oberman [EMAIL PROTECTED] wrote: You don't set up an IPv6 network. You simply have end nodes that will use IPv6 when/if it is available by just making a one-line change in rc.conf as opposed to a kernel re-build. But to make it (an ip v6 network) useful, I (as an end user) would need a dns domain for the machines I control, preferable a zone that *I* have control over. In other words; if I have machines with ipv6 adresses that I can reach globally, but don't have a dns name for them, the usefulness is very limited. Is that challenge solved somehow with ipv6? It doesn't look like dyndns.org supports ipv6 in their free service. Talk to dyndns.org. From a protocol perspective all this was solved years ago. Windows boxes use UPDATE everyday to do this. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INET6 required for SCTP in 7.0?
On Wed, 5 Mar 2008, Mark Andrews wrote: It would be better to remove the option all together. IPv6 is no longer a protocol under development. There is no need to make it optional any more. Having it there really sends the wrong signal. With all due respect, let's face a couple of facts. IPv4 is going to be the primary protocol for several years to come. There are a few critical reasons, and few people like to point out just how naked the emperor is: - Providing IPv6 currently (and for the forseeable future) provides no return on investment (ROI). Service Providers can't make more money with IPv6, businesses do not get any sort of competitive or perceived advantage from deploying IPv6, and end users certainly don't want to deal with it. Service providers get paid to push IP packets. They shouldn't care which protocol version is in the header. What they should be worried about is ensuring that they are here in 4 years time. It actually takes time to fill in the missing pieces and the only way to find the missing pieces is to bring up IPv6 networks. Most end users won't even know that they are running IPv6 connections. I had to look at netstat to see which protocol was being choosen on my father's box. I'm sure he had zero knowledge that he was using IPv6 (6-to-4). An IPv6 network really is as easy if not easier to run than a IPv4 network. - To route IPv6 with the same features and packet forwarding rate as with IPv4, nearly every network will be forced to purchase expensive router upgrades with no other real benefit beyond IPv6 connectivity (which again provides no ROI to justify the capex). Nobody is going to do forklift upgrades just for IPv6, but as routers get normally upgraded IPv6 functionality will indeed slowly expand. And the same arguement was put out 6 years ago. The backbone really has gone dual stack while you wern't paying attention. What's needed now is the SOHO CPE equipment sold to the non Asian market to catch up. - IPv6 provides almost no technological upgrades beyond additional address space. DHCP addressed the auto configuration feature, VPNs addressed IPsec. That extra address space really is a big advantage. It really is so much better to be able to get to machines you need to without have to manually setup application relays because you couldn't get enough address space to be able to globally address everything want to. - IPv4 address spaces will eventually transition to a market commodity model, providing a financial incentive that will encourage significant optimization and provide motive for providers to audit their allocations, and for businesses to part with IP space that they no longer properly utilize. The cost of acquiring IPv4 space will be less than the cost of upgrading to IPv6. Therefore, given a lack of ROI or sufficient technological motivation, and given the significant potential for optimization of existing IPv4 space both via technology and financial incentive, I see a minimum of five years before IPv6 is common. In the meantime, I'd like to only enable IPv6 on IPv6 enabled networks. So make the network IPv6 enabled. Both my home network and the office networks have bee IPv6 enabled for years now. My ISP doesn't support IPv6 yet though I know that have IPv6 netbocks for themselves now if not for the customers at this stage. There is a reasonable chance that this mail will leave here over IPv6 for some of the recipients. It will almost certainly travel over IPv6 for at least one hop. Mark Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INET6 -- and why I don't use it
if I had reasons to, but I've none, therefore I do not. Sufficient? -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INET6 required for SCTP in 7.0?
On 2008-03-05 22:42, Peter Wemm wrote: Oh, one more thing. If you are IPv6-enabled, you get to bypass the 10 minute greylisting delay on mx1.freebsd.org. Your email goes through instantly instead of potentially being delayed by 10-30 minutes. Until the spammers start using IPv6... Then we'll know it's gone mainstream. :/ They do it now. :-) Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INET6 -- and why I don't use it
On Mar 5, 2008, at 17:31 , Mark Andrews wrote: On Wed, Mar 05, 2008 at 03:00:29PM +, Vadim Goncharov wrote: * The last I read about IPv6 in mainstream news, there were major concerns cited over some of the security aspects of the protocol. I also remember reading somewhere that IPv6 was supposed to address issues like packet spoofing and DoS -- what became of this? Someone was feeding you a load of horse @$$!. When Marcus Ranum is one of those questioning its security, I'm inclined to believe him. (Google mjr ipv6 security --- his point in a nutshell is that we're going to be fixing old IPv4 holes in new guises for a while.) Unless you implement BCP 38 you won't prevent spoofed packets leaving your network. Nothing prevents someone injecting spoofed packets. It's just a matter of how far they travel. Unless you enable IPSEC for all your communication partners you won't be able to detect spoofed packets arriving. There is nothing anyone can really do to prevent a DoS attack. These statements are as true for IPv4 as they are for IPv6. IPv6 still has a MUST against IPSEC against this though people are arguing that it should become a SHOULD. That MUST indicates code support not enabling. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INET6 required for SCTP in 7.0?
Hi Xin LI! On Mon, 03 Mar 2008 16:50:33 -0800; Xin LI wrote about 'Re: INET6 required fo r SCTP in 7.0?': I'm not interested in enabling support for IPv6 for now. When I remove INET6 from the kernel configuration, I cannot compile the kernel without disabling SCTP. With fresh 7.0-STABLE source, here's the error output (INET6 disabled, but SCTP enabled): Yes, INET6 is (currently) required if you enable SCTP. Will it be fixed? Any time soon? It would be better to remove the option all together. IPv6 is no longer a protocol under development. There is no need to make it optional any more. Having it there really sends the wrong signal. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0 - slow/unstable Internet access via Linux router
On Mon, Mar 03, 2008 at 02:30:01PM +0300, Dmitry Antipov wrote: Is it required to have 'options INET6' even if I'm not using any IPv6 connectivity ? No, not unless you rely on SCTP, which at this time *does* require INET6. If you remove INET6, you must also remove SCTP. Be aware that if you remove INET6, ntpd (if used) will complain about missing transport protocol capability for tcp6 and udp6. It's a harmless warning, and won't impact functionality of ntpd. There is an open PR for this problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/78728 Also I have occasional 'mskc0: Uncorrectable PCI Express error' messages, which is a known (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/119613) problem... Can't help you with this, but I bet Pyun YongHyeon can. :-) I really don't understand this wish people have to turn off IPv6. The world is running out of IPv4 addresses. IPv6 will be required within a year or two. Now is the time to make sure every piece of software you use that requires IP connectivity supports IPv6. In 2-3 years time it will be too late as you won't have the option to fall back to IPv4. IPv6 connectivity is available to everyone today if they wish it. You don't have to wait for you ISP to supply it. What I want to see is a knob that turns off all IPv4 support so I can find the missing pieces easily. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0 - slow/unstable Internet access via Linux router
On Monday 03 March 2008 19:07:38 Mark Andrews wrote: On Mon, Mar 03, 2008 at 02:30:01PM +0300, Dmitry Antipov wrote: Is it required to have 'options INET6' even if I'm not using any IPv6 connectivity ? No, not unless you rely on SCTP, which at this time *does* require INET6. If you remove INET6, you must also remove SCTP. Be aware that if you remove INET6, ntpd (if used) will complain about missing transport protocol capability for tcp6 and udp6. It's a harmless warning, and won't impact functionality of ntpd. There is an open PR for this problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dbin/78728 Also I have occasional 'mskc0: Uncorrectable PCI Express error' messages, which is a known (http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/119613) problem... Can't help you with this, but I bet Pyun YongHyeon can. :-) I really don't understand this wish people have to turn off IPv6. The world is running out of IPv4 addresses. IPv6 will be required within a year or two. Now is the time to easy, you do not need ipv6 when you are on an ipv4 network make sure every piece of software you use that requires IP connectivity supports IPv6. In 2-3 years time it will be too late as you won't have the option to fall back to IPv4. What does turning off IPv6 get you other than a few less bytes of code? IPv6 connectivity is available to everyone today if they wish it. You don't have to wait for you ISP to supply it. well, that might not be exactly true, what do you want (and why should you) with an ipv6 address/service on your computer when you are on an ipv4 network??? The ability to actually *test* that a application that you use will work over IPv6. This is something that everybody that uses a networked application should be doing. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's new on the 127.0.0/24 block in 7?
://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's new on the 127.0.0/24 block in 7?
Quoting Royce Williams [EMAIL PROTECTED]:
Jeremy Chadwick wrote, on 3/3/2008 5:21 PM:
On Mon, Mar 03, 2008 at 05:43:35PM -0800, Chris H. wrote:
I've looked at this software: http://www.corpit.ru/mjt/rbldnsd.html
Why exactly do you need this software to bind to 127.0.0.2 or 127.0.0.3?
I don't see any indication of it needing that. DNS-based RBLs don't
work like that, so I'm confused by this request.
Indeed. You are /quite/ correct. I /do/ in fact run the BIND on the same
servers, and /do/ forward requests to the same servers primary address
(IP). But on a different port eg;
blackvoid.mydomain.COM {
type forward;
forward only;
forwarders { servers primary IP port 530; };
};
Hell, this is right out of the BIND FAQ that comes with the FreeBSD
BIND port.
/However/, rbldnsd needs to /answer/ when it finds a match, and answers:
IN A 127.0.0.2 REJECTED! evil spammer...
What does the addresses returned by a DNS lookup have to
do with what addresses are configured on lo0?
The answer is NOTHING.
So. This is what I mean by needing 127.0.0.? other than 127.0.0.1.
Which brings me 'round to my original question:
What has changed in 7 regarding 127.0.0/24 (lo0 || loopback).
I have identical server setups/configs on 2 servers. The recent RELENG_6
server creates/provides 127.0.0/24 without question. While 7-RC3 only
provides 127.0.0.1.
Thanks for taking the time to respond.
--Chris H
It's not uncommon to configure BIND to forward requests for a DNSBL
zone to another local listener, so that one can take advantage of both
BIND local zones and rbldnsd local zones.
See http://www.njabl.org/rsync.html for an example -- the BIND config
of which looks like:
zone dnsbl.njabl.org IN {
type forward;
forward first;
forwarders {
127.0.0.1 port 530;
};
};
Royce
--
Royce D. Williams- IP Engineering, ACS
http://www.tycho.org/royce/ - PGP: 3FC087DB/1776A531
Amid a multitude of projects, no plan is devised. - Syrus
--
panic: kernel trap (ignored)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's new on the 127.0.0/24 block in 7?
Quoting Andy Dills [EMAIL PROTECTED]: On Mon, 3 Mar 2008, Chris H. wrote: Are you sure it's a /24 you are talking about? My 7.0 disks install 127.0.0.1/8 here. Really? Where did you get the install disc? Mine clearly doesn't. :( All I am provided is 127.0.0.1 - not 127.0.0.2,3... 127.0.0.1/8 just means 127.0.0.1 with a netmask of 255.0.0.0. It doesn't imply a default behavior of binding to any other address than 127.0.0.1. But I'm still really confused what you're trying to do... See, the idea of returning multiple 127.0.0.X addressess within RBL is to convey different information while using a single zone. In the beginning, the RBLs would just reply with 127.0.0.1 and use different zones to imply different contexts...now you use a single zone with different 127.0.0.X addresses to convey the same information. But...you don't actually do anything with that resolution beyond determine if a given record is listed or not. You don't actually need to configure or use the various 127.0.0.X addresses that might get returned. On the other hand, if you're using multiple rbldnsd instances, one per zone... hile it's a pain you can indeed configured rbldns to serve multiple zones. Or just bind the additional loopback instances Precisely! Sorry I apparently wasn't clearer in the beginning. According to my conversations with the author of rbldnsd, rbldnsd was returning REFUSED to all my requests on my FBSD-7 server. Because it was unable to communicate on 127.0.0.2. If it returned REFUSED it could communicate. REFUSED is a DNS rcode so the packet went to the server and a reply was returned. This is a problem with a access control list in the rbldnsd configuration. I can tell you that without ever having run rbldnsd. Even though it was bound to my internet routable IP, it still needed 127.0.0.2, because that was the IP associated with one of my zones (2 in all). However, I had no difficulties using 2 zones on my recent RELENG_6 server, (served out of 127.0.0.2, and 127.0.0.3). /This/ is why I felt there must be some difference between the 2 releases (FBSD). Anyway, I didn't want to spam the list soliciting advice on setting up rbldnsd - I already know how to do that. It just /appeared/ that there was some difference in the handling of lo0, and it's associated IP space. So, as I could find no info in src/UPDATING, or ports/UPDATING, nor the man pages. I thought I'd better ask here. BTW, /etc/netstart is a nice shortcut to avoid fatfingering an ifconfig. Thanks. That's good to know. My first thought, is to probably just assign a different netmask to lo0, in an effort to get the additional IP's. Then see if everything works as well as it did on my RELENG_6 server. Thanks again for your response. I think you really helped clear things up - though I still have no answer as to why there is a difference between the 2. Oh, well. Thank care. --Chris H Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's new on the 127.0.0/24 block in 7?
Quoting Mark Andrews [EMAIL PROTECTED]: Quoting Andy Dills [EMAIL PROTECTED]: On Mon, 3 Mar 2008, Chris H. wrote: Are you sure it's a /24 you are talking about? My 7.0 disks install 127.0.0.1/8 here. Really? Where did you get the install disc? Mine clearly doesn't. :( All I am provided is 127.0.0.1 - not 127.0.0.2,3... 127.0.0.1/8 just means 127.0.0.1 with a netmask of 255.0.0.0. It doesn't imply a default behavior of binding to any other address than 127.0.0.1. But I'm still really confused what you're trying to do... See, the idea of returning multiple 127.0.0.X addressess within RBL is t o convey different information while using a single zone. In the beginning, the RBLs would just reply with 127.0.0.1 and use different zones to imply different contexts...now you use a single zone with different 127.0.0.X addresses to convey the same information. But...you don't actually do anything with that resolution beyond determi ne if a given record is listed or not. You don't actually need to configure or use the various 127.0.0.X addresses that might get returned. On the other hand, if you're using multiple rbldnsd instances, one per zone... hile it's a pain you can indeed configured rbldns to serve multiple zones. Or just bind the additional loopback instances Precisely! Sorry I apparently wasn't clearer in the beginning. According to my conversations with the author of rbldnsd, rbldnsd was returning REFUSED to all my requests on my FBSD-7 server. Because it was unable to communicate on 127.0.0.2. If it returned REFUSED it could communicate. REFUSED is a DNS rcode so the packet went to the server and a reply was returned. This is a problem with a access control list in the rbldnsd configuration. I can tell you that without ever having run rbldnsd. Yes, of course. Sorry, my bad. RBLDNSD's /log/ files contain REFUSED. The dig, host,nslookup queries return ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 58463 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 Sorry. I should have taken more time to answer. --Chris H Which doesn't change the diagnosis. You are talking to the caching server which is talking to rbldnsd which returns REFUSED. When the caching server runs out of servers to try it returns SERVFAIL to the original querier. P.S. you can test the rbldnsd directly if you want. dig -p port +norec @address query Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading to 7.0 - stupid requirements
Marko Lerota wrote: In http://www.freebsd.org/releases/7.0R/announce.html says Updating Existing Systems An upgrade of any existing system to FreeBSD 7.0-RELEASE constitutes a major version upgrade, so no matter which method you use to update an older system you should reinstall any ports you have installed on the machine. This will avoid binaries becoming linked to inconsistent sets of libraries when future port upgrades rebuild one port but not others that link to it. This can be done with: # portupgrade -faP etc... Why!!! If you never rebuild any ports at all after upgrading to a new major version, then your ports should all continue to work as long as they can find the old libraries they need. However, once you rebuild a port, it will link to new libraries, and may also link to other libraries that continue to be linked to the old libraries. You may end up with a binary being linked against libc.so.6 and libc.so.7, which will not work. Then the servers. Why should I reinstall all my databases and such? I always liked that FreeBSD base (OS) is separated from packages. And no matter what I do with the packages, my OS will always work. I don't want dependency hell like in Linux. Now you are telling me that my database might not work after upgrade to a new version. Is that it? Ports that depend on other ports are vulnerable to this problem. Ports that only require base libraries are not. The more ports a port depends on, the more likely you are to run into problems if you don't rebuild all ports to begin with. So, if you don't ever rebuild any of your ports at all, everything should still work until you finally do rebuild a port. At that point, if that port doesn't depend on other ports and only links to base libraries, you'll still be fine. Once you rebuild a port that depends on other ports, things may break if you don't force a rebuild of every port that port depends on. Running portupgrade -nrR package-list repeated until package-list stabilised used to also work for just-in-time upgrades like this. Unfortunately portupgrade -nrR no longer reports packages that won't be upgraded. There are no longer any - entries in the output. I need to see what portupgrade -nrRf does before reporting this. The paragraph you quoted above attempts to avoid that breakage and the mailing list questions that ensue, by forcing a rebuild of all ports to begin with. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading to 7.0 - stupid requirements
Marko Lerota wrote:
In http://www.freebsd.org/releases/7.0R/announce.html says
Updating Existing Systems
An upgrade of any existing system to FreeBSD 7.0-RELEASE constitutes
a major version upgrade, so no matter which method you use to update
an older system you should reinstall any ports you have installed on
the machine. This will avoid binaries becoming linked to inconsistent
sets of libraries when future port upgrades rebuild one port but not
others that link to it. This can be done with:
# portupgrade -faP
etc...
Why!!!
If you never rebuild any ports at all after upgrading to a new major
version, then your ports should all continue to work as long as they can
find the old libraries they need. However, once you rebuild a port, it
will link to new libraries, and may also link to other libraries that
continue to be linked to the old libraries. You may end up with a binary
being linked against libc.so.6 and libc.so.7, which will not work.
Then the servers. Why should I reinstall all my databases and such? I
always
liked that FreeBSD base (OS) is separated from packages. And no matter
what I
do with the packages, my OS will always work. I don't want dependency
hell like in Linux. Now you are telling me that my database might not work
after upgrade to a new version. Is that it?
Ports that depend on other ports are vulnerable to this problem. Ports
that only require base libraries are not. The more ports a port depends
on, the more likely you are to run into problems if you don't rebuild all
ports to begin with.
So, if you don't ever rebuild any of your ports at all, everything should
still work until you finally do rebuild a port. At that point, if that port
doesn't depend on other ports and only links to base libraries, you'll
still be fine. Once you rebuild a port that depends on other ports,
things may break if you don't force a rebuild of every port that port
depends on.
Running portupgrade -nrR package-list repeated until
package-list stabilised used to also work for just-in-time
upgrades like this. Unfortunately portupgrade -nrR no
longer reports packages that won't be upgraded. There are
no longer any - entries in the output.
I need to see what portupgrade -nrRf does before reporting
this.
For example if I was to upgrade firefox I'd have to upgrade
548 of the 582 packages on this machine.
Mark
getlist:
#!/bin/sh -f
sed -e '/Depends on:/d' \
-e '/Information for/d' \
-e '/Required by:/d' \
-e '/^$/d' \
-e 's/Dependency://' \
-e 's/ //g' |
sort -u
% pkg_info -rR *fox* | ./getlist | wc
100 1001665
% pkg_info -rR *fox* | ./getlist | xargs pkg_info -rR | ./getlist | wc
467 4678435
% pkg_info -rR *fox* | ./getlist | xargs pkg_info -rR | ./getlist | xargs
pkg_info -rR | ./getlist | xargs pkg_info -rR | ./getlist | wc 547
5479780
drugs:9.4.x 14:03 {2701} % pkg_info -rR *fox* | ./getlist | xargs pkg_info
-rR | ./getlist | xargs pkg_info -rR | ./getlist | xargs pkg_info -rR |
./getlist | xargs pkg_info -rR | ./getlist | wc
548 5489793
% pkg_info -rR *fox* | ./getlist | xargs pkg_info -rR | ./getlist | xargs
pkg_info -rR | ./getlist | xargs pkg_info -rR | ./getlist | xargs pkg_info -rR
| ./getlist | xargs pkg_info -rR | ./getlist | wc
548 5489793
% pkg_info | wc
5823869 34258
%
The paragraph you quoted above attempts to avoid that breakage and the
mailing list questions that ensue, by forcing a rebuild of all ports to
begin with.
--
Skip
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
Patient: Doctor, it hurts when I do this! Doctor: Don't do that... Did you actually bother to read his report? While his example is used /, if the report is correct then you just need to replace / with the path of any file system mount point that is world writable like say /tmp. Do you have /tmp mounted like this? /dev/ad0s4e507630 162050 30497035%/tmp Have you tried using /tmp or some other suitable mount point before slinging off with the old Doctor joke? Even if it is only /, having the system die and not be recoverable due to having a excessive number of files in / is a critical error. I'm sure you have *never* accidently copied a set of files to / in your life. Me, I know I've made that sort of mistake in the past, and as I'm not perfect, I'm sure I'll make that sort of mistake at some point in the future. I would however like the machine not to fallover when I do make that mistake. Now why don't you be constructive and verify whether the report is valid or not. I don't have a spare machine to test it on so I'm not going to attempt it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't delete IPV6 addresses with ifconfig
I'd like to know what goes on behind the mask. I sifted through /etc/rc.d and so on but it's not very clear. See sysctl net.inet6.ip6.auto_linklocal I actually tried setting that but it had no effect..=20 I can't find any documentation on it (in inet6 or ip6) net.inet6.ip6.auto_linklocal is cleared, based on, ipv6_enable really early in the boot process before any interfaces are configured (see rcorder). When the interface is attached the kernel will auto configure a link local address if net.inet6.ip6.auto_linklocal is still 1. grep for auto_linklocal in the kernel sources for all the details. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't delete IPV6 addresses with ifconfig
--nextPart1996860.fztbeObibp Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I am experimenting with IPv6 and I can't seem to remove an IPv6 address=20 from an interface, eg I have.. [midget 22:11] ~ ifconfig fxp0 fxp0: flags=3D8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu=20 1500 options=3DbRXCSUM,TXCSUM,VLAN_MTU inet 10.0.2.1 netmask 0xff00 broadcast 10.0.2.255 inet 10.0.2.3 netmask 0x broadcast 10.0.2.3 inet 10.0.2.4 netmask 0x broadcast 10.0.2.4 inet 10.0.2.7 netmask 0x broadcast 10.0.2.7 inet6 2002:792d:8527::1:1 prefixlen 64 ether 00:02:b3:32:2c:51 media: Ethernet 100baseTX status: active But I can't remove it, viz.. [midget 22:11] ~ sudo ifconfig fxp0 -alias 2002:792d:8527::1:1/64 ifconfig: 2002:792d:8527::1:1/64: bad value [midget 22:27] ~ sudo ifconfig fxp0 delete 2002:792d:8527::1:1/64 ifconfig: 2002:792d:8527::1:1/64: bad value [midget 22:27] ~ sudo ifconfig fxp0 delete 2002:792d:8527::1:1 ifconfig: 2002:792d:8527::1:1: bad value [midget 22:27] ~ sudo ifconfig fxp0 delete 2002:792d:8527::1:1=20 prefixlen 64 ifconfig: 2002:792d:8527::1:1: bad value [midget 22:27] ~ sudo ifconfig fxp0 delete 2002:792d:8527::/64 ifconfig: 2002:792d:8527::/64: bad value Anyone know the right way to do this? :) ifconfig fxp0 -alias inet6 2002:792d:8527::1:1 =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1996860.fztbeObibp Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHtCy15ZPcIHs/zowRAp4GAKCiDBhK5KnMRXAtHN9J9pJwbr9vTQCeLHtF H6WuTRDWwPdfOggg4inmxbw= =UEHW -END PGP SIGNATURE- --nextPart1996860.fztbeObibp-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't delete IPV6 addresses with ifconfig
--nextPart1526557.1B05VYlNaf Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 14 Feb 2008, Hajimu UMEMOTO wrote: doconnor Anyone know the right way to do this? :) sudo ifconfig fxp0 inet6 2002:792d:8527::1:1 -alias Ahah, thanks, that works. Now to work out how to get rtadv going :) bsdi# ps ax | grep rtadv 181 ?? Is 0:09.44 rtadvd tx0 36505 p1 S+ 0:00.01 grep rtadv bsdi# =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1526557.1B05VYlNaf Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHtDZS5ZPcIHs/zowRAj9bAJ9ujJF6n0o+zyXgKyQwvx0saglqzwCfdML8 F3e7nxGQXyYruOWythI/V3g= =iphe -END PGP SIGNATURE- --nextPart1526557.1B05VYlNaf-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't delete IPV6 addresses with ifconfig
Yes, after I created a link local address for fxp0 it worked fine. I had to do so manually though - I am not sure what is responsible for=20 making them. I just rebooted it and it seems OK now though.. Any idea what creates the link local address at startup? (Mainly to=20 satisfy my curiosity :) My border gateway has: ipv6_enable=YES ipv6_prefix_tx0=2001:0470:1F00:0820 fd92:7065:0b8e: ipv6_gateway_enable=YES rtadvd_enable=YES rtadvd_interfaces=tx0 I've also use a tunnel broker to get external connectivity called from /etc/dhclient_exit_hooks /usr/local/bin/perl -T /etc/tunnelbroker-update-0.07b.pl /etc/dhclient_exit_hooks also configures the 6to4 relay so that traffic to 6to4 addresses gets dumped to IPv4 as soon as possible. # #Configure 6 to 4 relay # octets=`echo $new_ip_address | sed 's/\./ /g'` ifconfig stf0 inet6 2002:`printf %02x%02x:%02x%02x $octets`:::1 \ prefixlen 16 alias deprecated link0 route add -inet6 2002:: -prefixlen 16 ::1 route change -inet6 2002:: -prefixlen 16 ::1 -ifp stf0 The laptop has: ipv6_enable=YES Both have firewalls, etc. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't delete IPV6 addresses with ifconfig
I'd like to know what goes on behind the mask. I sifted through /etc/rc.d and so on but it's not very clear. See sysctl net.inet6.ip6.auto_linklocal -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Rebuilding World Problems
Also, UPDATING has adjkerntz -i just before mergemaster -p. I=20 looked at the man page for adjkerntz and am still uncertain if I = need=20 to do this. I run an ntpd client, if that makes any difference. =20 Again, just a precaution. Think safe, or event free. :) Well when you live in front of UTC and use wallclock time because you dual boot with a OS that doesn't support the hardware clock at UTC, you end up waiting however many hours you are infront of UTC for make to work again properly. Last time I forgot it was a 11 hour wait. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/cuad0: Device busy
On Mon, Feb 04, 2008 at 02:08:32PM +0700, Eugene Grosbein wrote: Personally, I never understood the concept of dial-in and call-out devices on FreeBSD. I ran BBS software for years on both Apple II hardware and PC hardware; there was no distinction between such devices. A serial port is a serial port. Chances are I'm not understanding why there's a distinction, but there doesn't appear to be any explanation of why there's a distinction within manpages or the handbook... The distinction exists to allow an application to wait on the dial-in port for incoming calls and another application to make outgoing call mean time using the same port as call-out while the port is idle. This is intruiging to me, because now I'm left wondering how that actually works behind the scenes! :-) What happens when program X has /dev/ttyd0 open (for incoming calls), receives a call, and then during which program Y attempts to open /dev/cuad0? Does program Y indefinitely block/wait somewhere within the kernel until program X releases the fd? open blocks until CD is asserted when /dev/cuad0 is not open. If so, then I'm left wondering why Ganbold's cu -l cuad0 attempt returned an immediate EBUSY, rather than blocking indefinitely. EBUSY indicates that the open on /dev/ttyd0 completed. Also, the above mechanism must be fairly old, because I imagine it would be more effective to utilise kqueue/kevent to inform said programs of when the serial port is available for use. Only about 20 years old. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/cuad0: Device busy
Personally, I never understood the concept of dial-in and call-out devices on FreeBSD. I ran BBS software for years on both Apple II hardware and PC hardware; there was no distinction between such devices. A serial port is a serial port. Chances are I'm not understanding why there's a distinction, but there doesn't appear to be any explanation of why there's a distinction within manpages or the handbook... The distinction exists to allow an application to wait on the dial-in port for incoming calls and another application to make outgoing call mean time using the same port as call-out while the port is idle. And once there is a incoming call block out going calls until the incoming call completes. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PATCH: FreeBSD-7-BETA4 'bge' ether for Dell T105 server
Thanks to Max Laier's help, the ether device is now working with the 'bge'
driver. Here is a patch that makes it work. I just recompiled the
kernel afterwards and it comes up.
PS: the T105 is now $399 but includes 1GB RAM and 2x160GB disk,
in addition to the dual-core 1.8GHz Opteron and DVD reader.
(Is there a better way to do this? sorry for the CC's, wasn't sure which
was appropriate for getting this into the tree.)
send-pr is the appropriate command for submitting these sorts
of fixes.
$ pwd
/usr/src/sys/dev/bge
$ diff -c if_bge.c*
*** if_bge.c Mon Nov 26 12:33:28 2007
--- if_bge.c.NEW Sun Dec 23 15:44:40 2007
***
*** 169,174
--- 169,175
{ BCOM_VENDORID,BCOM_DEVICEID_BCM5715S },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM5720 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM5721 },
+ { BCOM_VENDORID,BCOM_DEVICEID_BCM5722 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM5750 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM5750M },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM5751 },
$ diff -c if_bgereg.h*
*** if_bgereg.h Tue May 22 15:22:58 2007
--- if_bgereg.h.NEW Sun Dec 23 15:44:53 2007
***
*** 2011,2016
--- 2011,2017
#define BCOM_DEVICEID_BCM5715S 0x1679
#define BCOM_DEVICEID_BCM5720 0x1658
#define BCOM_DEVICEID_BCM5721 0x1659
+ #define BCOM_DEVICEID_BCM5722 0x165a
#define BCOM_DEVICEID_BCM5750 0x1676
#define BCOM_DEVICEID_BCM5750M 0x167C
#define BCOM_DEVICEID_BCM5751 0x1677
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 1.3G of my /var missing
df -h reports that on /var 1.5G of 1.9G are used and only 237M of free space remain. However doing a du -hd 1 /var and summing up the results I only get to less than 200M of used space, so there are 1.3G unaccounted for. fsck in single user mode does not recognize a problem. The usual answer is that a process has a unlinked file open however as you went to single user this would have eliminated this. Are you swapping to a file on /var? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 1.3G of my /var missing
Clayton Milos wrote: Jeremy Chadwick wrote: On Wed, Oct 24, 2007 at 08:27:10AM +0200, [LoN]Kamikaze wrote: ... and summing up the results I only get to less than 200M of used space, so there are 1.3G unaccounted for. fsck in single user mode does not recognize a problem. Try looking at tunefs(8), particularly the -m flag. That amount of space is kept for root (the user). As in most cases the problem was sitting between the chair and the keyboard. I simply overlooked the G when I read that /var/log contained 1.3G of data. I'm sorry for wasting the precious time of those who read or even replied with my stupidity. Sounds like you need to make a few entries in /etc/newsyslog First thing I do when I add any new apps is give their logs a life cycle. All too quickly logs become bulky and you find /var holding it's breath. -Clay The problem was messages, and it's related with my DVD troubles which spammed the log with DMA errors. If you let the tools do their jobs you won't get silly errors like that. Both du and df default to returning 1k blocks. You will note that the usage figure is identical by both methods. Mark drugs# du -s /var 404806 /var drugs# df /var Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s4d 2004526 404806 143935822%/var drugs# -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BIND 9.3.4 assertion failure on restart
On Thu, Oct 18, 2007 at 12:46:39PM -0700, Jeremy Chadwick wrote: ... So it may indeed be some BIND bug... Lo and behold, using -n 1 in named_flags works around the problem. I'm sure this impacts performance, but does help pinpoint the problem as being with BIND or possibly BIND on FreeBSD. I'm pretty sure this is fixed in BIND 9.3.5 which will go though release engineering once BIND 9.4.2 goes out the door. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
On Thu, 27 Sep 2007, Mark Andrews wrote: (I wrote:) On Tue, 25 Sep 2007, LI Xin wrote: Oliver Fromme wrote: Nicolas Rachinsky wrote: Oliver Fromme wrote: By the way, an additional confusion is that .. and ../ are handled differently. Specifying .. always leads to this message: rm: . and .. may not be removed and nothing is actually removed. It is confusing that adding a slash leads to a different error message _and_ removal of the contents of the parent directory. Clearly a POLA violation. Clearly a bug, and well spotted, especially if as old as reported. Adding a slash often leads to different behaviour. Yes, I'm aware of that. I often make use of the feature that find /sys/ expands the symlink, while find /sys does not. The same holds true for ls(1). But fortunately not for rm(1): The rm utility removes symbolic links, not the files referenced by the links. It is an error to attempt to remove the files /, . or .. However, I would still argue that there is no sane reason for rm -rf ../ behaving differently from rm -rf .., especially because it behaves differently in a destructive way. That's why I call it a POLA violation. Also a POSIX violation IMHO :-) Indeed; I can't imagine a situation where removing . (let alone ..) and so orphaning the pwd might be considered sane, never mind legal .. but maybe I lack imagination :) You lack imagination. No doubt :) When you found the directory you want to remove and you are in it it is much less error prone to remove . recursively that to go up one directory and try to find the directory you were just in. Sorry, I can't agree. I take comfort in knowing that 'rm .' will fail, that 'rm *' will not remove '.' (let alone '..'!), and that rm will not orphan the pwd. Neither will umount, for that matter .. You asked to be shown a example. It's a perfectly reasonable example. The the prohibitions comes from when you literally removed directories by unlinking the directory and . and .. within the directory in user space. It was easy to stuff up a directory structure. Regardless of how implemented in the filesystem, having the pwd become invalid isn't something I ever expect to happen, and I'll continue to rely on: 'It is an error to attempt to remove the files /, . or ..' It's something that you need to expect on a multi-process system. It happens to me one or twice a month. Mark Cheers, Ian -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
On Tue, 25 Sep 2007, LI Xin wrote: Oliver Fromme wrote: Nicolas Rachinsky wrote: Oliver Fromme wrote: By the way, an additional confusion is that .. and ../ are handled differently. Specifying .. always leads to this message: rm: . and .. may not be removed and nothing is actually removed. It is confusing that adding a slash leads to a different error message _and_ removal of the contents of the parent directory. Clearly a POLA violation. Clearly a bug, and well spotted, especially if as old as reported. Adding a slash often leads to different behaviour. Yes, I'm aware of that. I often make use of the feature that find /sys/ expands the symlink, while find /sys does not. The same holds true for ls(1). But fortunately not for rm(1): The rm utility removes symbolic links, not the files referenced by the links. It is an error to attempt to remove the files /, . or .. However, I would still argue that there is no sane reason for rm -rf ../ behaving differently from rm -rf .., especially because it behaves differently in a destructive way. That's why I call it a POLA violation. Also a POSIX violation IMHO :-) Indeed; I can't imagine a situation where removing . (let alone ..) and so orphaning the pwd might be considered sane, never mind legal .. but maybe I lack imagination :) You lack imagination. When you found the directory you want to remove and you are in it it is much less error prone to remove . recursively that to go up one directory and try to find the directory you were just in. The the prohibitions comes from when you literally removed directories by unlinking the directory and . and .. within the directory in user space. It was easy to stuff up a directory structure. Mark Cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BIND 9.3.1 - How to get rid of AAAA querys?
I have been running IPv6 on all of my FreeBSD work systems for years. All of my mail (including this message) are sent/received by IPv6 and I have not had any problems, but I am on a network that is fully IPv6 enabled, so no tunnels are involved. That's good to know. I have one box on the live internet (mail.twisted.org.uk ) which is runnign 6.2-STABLE and using 6to4 to provide IPv6 to those whowant i t. Some of our outgoing mail gets delivered over IPv6, but none of our incomming does. However it does seem to behave itself. I do know that there will be a major re-write of IPv6 support in V7 to integrate the KAME code into the rest of the network as KAME is not longer separately developed. I'm not sure how this will impact things, That was going to be the next point where I tested it (when V7 comes out). My home machine works more-or-less ine using IPv6 on 6to4, with the only problems being when ftping large files to/from twisted.org.uk which show a random disconnect after 10-20 minutes of transfer. My bigger problem is trying to distribute my IPv6 address to machines behind the single box which faces the outside world (as thats what IPv6 is good for right ? No more NAT?). These boxes work in so far as they can all see and ping IPv6 addresses and make and receive TCP connections. But if, for example, I make a TCP connection to www.kame.net then I get the first chuink of data but then a freeze for a long period of time before the rest of the data arrives. This does not happen from the direct machine, it sees all the data at once. I suspect that ICMP messages are being filtered causing PTMU discover to rely on timeouts rather than error messages. I'm amazed that people still filter ICMP. It is a integral part of IP and really should not be filtered. Yes I know why people started filtering ICMP. However the filter should be for directed broadcasts not ICMP. Unfortunately that problem makes IPv6 useless for me on the inteernal network behind the box, so it's been disabled. I am reluctant to deploy it on work machines for the same reson. Diirectly connected boxes may work fine but actiually trying to use IPv6 to get rid of NAT doesn't seem to work right . Sadly I haven't had any time to investigate further. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BIND 9.3.1 - How to get rid of AAAA querys?
Andreas Pettersson wrote: Mark Andrews wrote: Why don't you go the other way and get yourself IPv6 connectivity. You do realise that you will require it to reach many sites in about 3 years time as they will be IPv6 only For almost 10 years I've heard discussions about the successor to IPv4, but from my point of view (may differ from others..) not much has happened. Of course, I can imagine that when the wheel starts rolling for real things might change quickly. 3 years may prove to be correct, but are there any clear signs pointing in this direction? The proponents of IPv6 have claimed growing real-world deployment for the last several years. There is yet no significant commercial deployment--the real world still runs on IPv4. The mitigating factors are IPv4 address space pressure and global routing problems. Every time enough people start crying about too little IPv4 address space left, IANA reassigns more reserved space into the allocation pool and those fussing grow quiet. As for global routing, it can be summed as: it ain't broken enough, yet. It's going to be years before there is a real, sustained pressure to migrate significant portions of the commercial internet into IPv6 space and years more for enough key-player migration to drag the rest of the commercial world with it. The academic and research portions of the internet are not the driving force. Convince MSN, AOL, Yahoo, Comcast, $BIG_NATIONAL_ISP, etc. to deploy IPv6 and we'll get wide-spread global IPv6 deployment overnight. I'll put it this way: When my Linksys WRT54G supports IPv6 on both sides of the router, IPv6 will have reached commercial viability. Until then, it's a research exercise. Apple's Airport enables IPv6 support by default today. If you plug it in and you have a IPv6 enabled host it will get a globally addressable IPv6 address. There are roughly 3 billion unicast IPv4 addresses. We need to address more than 3 billion machines. Even with NAT and double NAT we will run out of address. DOCCIS 3.0 does its management over IPv6. The big cable providers are moving to IPv6 today even if they arn't supplying IPv6 to the customers yet. Mark -- Darren Pilgrim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BIND 9.3.1 - How to get rid of AAAA querys?
On Thu, 13 Sep 2007, Darren Pilgrim wrote: Andreas Pettersson wrote: Mark Andrews wrote: Why don't you go the other way and get yourself IPv6 connectivity. You do realise that you will require it to reach many sites in about 3 years time as they will be IPv6 only For almost 10 years I've heard discussions about the successor to IPv4, bu t from my point of view (may differ from others..) not much has happened. Of course, I can imagine that when the wheel starts rolling for real things might change quickly. 3 years may prove to be correct, but are there any clear signs pointing in this direction? The proponents of IPv6 have claimed growing real-world deployment for the last several years. There is yet no significant commercial deployment--the real world still runs on IPv4. Just adding another real world datapoint... I'd love to get my hands dirty with IPv6. I contacted both of our upstreams, Level3 and HE.net. Level3 never responded, if anyone has details on what their deal is, please share (offlist). HE.net wanted both more money and for us to order another port with them. HE claim they are now dual stacked. You shouldn't need a second port. For the 0.0001% of our users that have expressed interest in v6 connectivity, we're not going to pay for another FE port just to experiment. I'm sure most other Tier-2 local/regional ISPs feel the same way. If there were a free and best effort service offered by any of our upstreams though, I'd jump at it. My buddy Ike over at NYCBUG does have a bunch of pictures of cheap consumer IPv6 home routers from his trip to Japan. Apparently it's quite widespread there. Charles -- Darren Pilgrim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BIND 9.3.1 - How to get rid of AAAA querys?
When looking in the querylog for BIND 9.3.1 running on FreeBSD 5.4, almost every other log entry specifies an query. The only client is localhost. I see no reason right now to have BIND wasting resources on IPv6 requests, so I added named_flags=-4 to rc.conf and restarted named. Sockstat tells me named is listening only on udp4 and tcp4, but I still get lots of entries in the querylog: 12-Sep-2007 21:40:47.129 client 127.0.0.1#60103: query: smtp.secureserver.net IN + 12-Sep-2007 21:40:47.648 client 127.0.0.1#64489: query: smtp.where.secureserver.net IN + 12-Sep-2007 21:40:47.847 client 127.0.0.1#61673: query: smtp.secureserver.net IN A + 12-Sep-2007 21:40:47.869 client 127.0.0.1#53040: query: mailstore1.secureserver.net IN + 12-Sep-2007 21:40:47.871 client 127.0.0.1#54473: query: mailstore1.secureserver.net IN A + 12-Sep-2007 21:40:58.261 client 127.0.0.1#58124: query: 120.86.248.87.in-addr.arpa IN PTR + 12-Sep-2007 21:40:58.340 client 127.0.0.1#56511: query: static-ip-87-248-86-120.promax.media.pl IN + 12-Sep-2007 21:40:58.410 client 127.0.0.1#61212: query: static-ip-87-248-86-120.promax.media.pl IN A + What can I do to get rid of these? Teach each and every application not to make them. :-) -4 stops named *making* and accepting queries *over* IPv6. It does NOT stop it accepting queries. It does NOT stop it making queries. Why don't you go the other way and get yourself IPv6 connectivity. You do realise that you will require it to reach many sites in about 3 years time as they will be IPv6 only (new IPv4 address space is running out real soon now). Running dual stacked now is how you debug you system. If you ISP doesn't yet offer IPv6 natively there are lots of alternate method. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: wpa_supplicant features and compile options
On 12/23/-58 20:59, Greg Rivers wrote: div class=moz-text-flowedI connect to certain wireless networks that require the EAP_GTC and EAP_OTP features in wpa_supplicant. These features are not compiled into wpa_supplicant by default. Using the patch below works great, but it's inconvenient having to remember to apply it after every cvsup. Is there a better way to accomplish this? If not, might a change such as this be committed to enable GTC and OTP by default? Greg, I'm unable to comment on including your patch into cvs, but for own patches like your's, I'm using a script which does 1) csup and 2) integrate a bunch of patches into /usr/src. HTH Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Or you can transfer the cvs repository and update your source tree from that using cvs. You just leave the local changes uncommitted. Alteratively you can cvs import the FreeBSD src periodically. You can then commit local changes. This can also make it easy to roll back to your previous build state. This should take less disk space than the previous solution. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NZ Daylight Savings changes.
On Wed, Aug 22, 2007 at 11:38:21AM +1200, Jonathan Chen wrote: Would it be possible for a committer to take a look at: http://www.freebsd.org/cgi/query-pr.cgi?pr=115697 There's only about a month or so before the new daylight savings rule becomes effective, and it would be nice if -STABLE had the changes committed before then. The port misc/zoneinfo has been updated with the 2007g version of the zoneinfo files, I'm going to see if I can get approval of re@ to commit this. Which really needs to be properly integrated into the base system with a NO_something to prevent the database being clobbered when the system is rebuilt. Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://www.mavetju.org/weblog/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named.conf restored to hint zone for the root by default
Jeremy Chadwick wrote: On Thu, Aug 02, 2007 at 01:49:39PM -0700, Doug Barton wrote: Oliver Fromme wrote: Hi, Just for the record, I like the current solution, i.e. default being a hint zone, and slave zones being commented out, ready to be used for those who know what they're doing. I second this. And although I like Doug's use of AXFR from the roots (like others reported, it definitely speeds things up), I also want to continue to respect rootserver operators and dns-ops's concerns. Something that I haven't mentioned but I think is probably worth pointing out is that at least for Paul Vixie (operator of f.root) the concern is not for the root servers, it's for potential problems on the client side. The following is from http://lists.oarci.net/pipermail/dns-operations/2007-August/001920.html i remain perplexed about the general perception that AXFR is bad for a root name server. it's not. RFC1035 describes some resource management techniques for TCP state blobs, which the root servers follow. the chance that an AXFR will be blown away by a TCP query is very high, and so, it's bad for clients to make production use of AXFR from busy servers.i remain perplexed about the general perception that AXFR is bad for a root name server. it's not. RFC1035 describes some resource management techniques for TCP state blobs, which the root servers follow. the chance that an AXFR will be blown away by a TCP query is very high, and so, it's bad for clients to make production use of AXFR from busy servers. The 3 zones in question are actually really small: -rw-r--r-- 1 bind wheel 1.6K Aug 2 14:25 arpa.slave -rw-r--r-- 1 bind wheel23K Aug 2 14:24 in-addr.arpa.slave -rw-r--r-- 1 bind wheel64K Aug 2 14:30 root.slave so I'm not sure how much of a problem this is in practice. I also suspect that using accept filters will mitigate some of the problem. If someone was to write a DNS accept filter that would help. So offering the template configuration to do so, but not enabling it by default, is a very good thing. Thank you for doing this, Doug. Glad to do it. I'm also glad to see that this topic is getting serious discussion. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named.conf restored to hint zone for the root by default
Hi, Just for the record, I like the current solution, i.e. default being a hint zone, and slave zones being commented out, ready to be used for those who know what they're doing. However, I noticed that the refresh interval of the root zone is 1800, i.e. it would be fetched every 30 minutes, even though the zone seems to be updated at most once per day. Therefore, wouldn't it make sense to add the following option to the slave zones? No, it is *NOT* fetched ever 30 minutes. The SOA is queried every 30 minutes (via UDP) and if the serial has increased then the zone is fetched. min-refresh-time 86400; No. Let the root server operators make that choice. The refresh / retry limits in named are there for ISP's which slave 10's of thousands of client zones. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl will consistently give you what you want, unless what you want is consistency. -- Larry Wall ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
I don't think that all of the drama could have been avoided in any case, there is too much emotion surrounding this issue. I'll concur with Doug on this. I've been discussing doing just this for the last 10+ years. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Mark Andrews wrote: I don't think that all of the drama could have been avoided in any case, there is too much emotion surrounding this issue. I'll concur with Doug on this. I've been discussing doing just this for the last 10+ years. Why don't you update 2870 then to make it so? Why don't you? You seem to be the one worried about it :-) I want to get draft-ietf-dnsop-default-local-zones through first before dealing with the issue of how to get every iterative resolver serving the root. You will note that dealing with traffic at the root is left out of draft-ietf-dnsop-default-local-zones. If all the roots provided it and were required to, there's no problem. But current best practice as defined by 2870 are for roots to only answer AXFRs from other roots. How can you advocate an OS pushing a configuration that isn't guaranteed to be functional? I understand the odds of it breaking, and I understand the benefits. That's not the issue. There is a difference between saying we should do this and just doing it. Part of process is to get consenus that this is reasonable or at least won't hurt and working what needs to be changed to make it happen. This is a configuration that should be guaranteed to work for 2 years after every OS release that includes it. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD violates RFC2870 [was: Re: Problems with named default configuration in 6-STABLE]
On Tue, Jul 17, 2007 at 12:47:50PM +0200, Volker wrote: As I think having a default to hint root zone is better, I'll file a PR about that. Which leads me to ask: Why hasn't anyone recommended using stub zones for this? It seems the goal is to cache NS records from the rootservers, and stub zones don't utilise AXFR/IXFR. Because a root server (stealth slave) can generate the NXDOMAIN responses locally. This really is a big win for ISP's where there are lots of leaked queries for private tlds, IPv4 addresses etc. Whether there is a benefit for everyone is still open to debate. Mark -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with named default configuration in 6-STABLE
On 07/17/07 11:06, Heiko Wundram (Beenic) wrote: On Tuesday 17 July 2007 10:52:43 Volker wrote: snip Relying on a zone transfer doesn't seem to be reliable to me as more than half of the root servers doesn't reply to AXFR requests. I've heard pretty much the same thing as you did wrt. root name servers denying AXFR, but as it works (TM), I don't see a reason not to use it. A nd it seems that the author of the FreeBSD default named.conf thought likewise , which is pretty okay with me (from the experience I gathered this morning). By the way: using the roots as hints only adds to the number of requests yo ur server has to do in order to retrieve first-level domain name servers, so i n the end, the transmitted data should be way higher than doing one AXFR to find them (simply because you'll see a large subset of those toplevel domai ns being requested when you're publically offering a DNS server). And the data is also cached on an AXFR in persistant storage, which is another major benefit (for me). Remember, AXFR requires a TCP transfer and not every firewall will happily let it pass. Then the firewall is misconfigured. Ordinary DNS lookups can require TCP. That's what the tc flag is for. I (partially) agree to the speedup effects you mentioned but if just 5 out of 13 root servers support AXFR, your bind will sit for a while to find a root server responding to it's AXFR requests. That may eat up your speed improvements. Type hint for the root zone always works (regardless of the firewall and which root server is being queried). Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with named default configuration in 6-STABLE
--nextPart2302559.jWhKoKUfrP
Content-Type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Tuesday, 17. July 2007, Volker wrote:
On 07/17/07 09:20, Michael Nottebrock wrote:
On Tuesday, 17. July 2007, Yuri Pankov wrote:
On Mon, Jul 16, 2007 at 11:19:41PM +0200, Michael Nottebrock wrote:
I finally updated my desktop from 5.5-RELEASE to 6-STABLE. This got me
a new named.conf, which I modified to run named as a local resolver,
like I had before:
listen-on { 127.0.0.1; };
listen-on-v6{ ::1; };
forward only;
forwarders {
192.168.8.1;
};
Everything else is default. However, with this default configuration,
named will not resolve any hosts of my local domain (my.domain), which
uses addresses in the 192.168.8 subnet. My dns server on 192.168.8.1,
running 6.2-RELEASE, has a very simple dynamic dns setup: a zone
my.domain and a reverse zone 8.168.192.in-addr.arpa which are both
dynamically updated by dhcpd.
To make this work again, I had to delete everything in the default
named.conf from /* Slaving the following zones from the root
[...] to zone ip6.int { type master;
file master/empty.db; };.
I'm a DNS n00b, but I suspect that such drastic measures shouldn't be
required and somehow my setup is flawed. What can I do to make this
work right?
Cheers,
--
,_, | Michael Nottebrock | [EMAIL PROTECTED]
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org
Hi Michael,
If I understood you correctly, you can't resolve 8.168.192.in-addr.arpa
anymore, and the line below (from default named.conf) is the cause:
zone 168.192.in-addr.arpa { type master; file master/empty.db; };
Yes - and this:
zone . {
type slave;
The root zone MUST be of type hint. You do not want to be a slave of
the root... don't you? ;)
The new default configuration of named wants me to be.
But now that you've mentioned it, I finally saw the following lines in the=
=20
default named.conf:
=2D--
If you do not wish to slave these zones from the root servers
use the entry below instead.
zone . { type hint; file named.root; };
=2D--
I scanned over that before, but being a DNS n00b, I didn't understand what =
it=20
meant. So, that solves that. Still, quite a bit of editing required:=20
Commenting out the slaved root zone, moving out the root servers hint out o=
f=20
a comment and commenting out the empty zone for my private use network to=20
make reverse lookups work again.
I think at least an UPDATING entry and maybe some more verbose and less=20
technical commenting in named.conf itself is warranted.
=2D-=20
,_, | Michael Nottebrock | [EMAIL PROTECTED]
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org
--nextPart2302559.jWhKoKUfrP
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQBGnHiIXhc68WspdLARAuSHAKCk7dskkSAzlAiquA48iGvGf+B88ACeOoj4
XfDcTp42hWrF4RFOnG1jE8c=
=bto6
-END PGP SIGNATURE-
--nextPart2302559.jWhKoKUfrP--
For a forward zone to work there has to be a zone cut between any
authoritative zones (master/slave) and the forward zone.
When you graft private namespaces onto the DNS tree slave / stubs
zones work better.
Forward zones and forwarders are over used.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FREEBSD_4_EOL tag, last known index file?
From Erwin Lansing [EMAIL PROTECTED], Mon, Jul 16, 2007 at 12:59:50AM +020 0: On Sun, Jul 15, 2007 at 03:05:30PM -0700, Jon Dama wrote: Is there a port index file that corresponds to the FREEBSD_4_EOL tag? I am unable to rebuild the index from the tagged checkout. The official INDEX file is no longer available nor supported. You should be able to build it by cd /usr/ports; make index'. If that I am aware of that. The trouble of course is that for whatever reason the make index target appears to fail--although I am not entirely convinced that this isn't a local problem. Still I would have expected that the tag point to at least be useable, meaning that make index would work. doesn't work for you, I'm afraid the only supported configuration is to upgrade to 6.2-RELEASE, which you probably want to do anyway, if not just because security fixes are not applied to earlier versions. Strictly speaking the EOL means that the base has been abandoned by the security officer and the ports collection, not that it is abandoned entirely. 4.x has been completely abandoned by the ports collection. Within days of EOL for 4.x there were changes made to ports make files to remove any vestages of support for FreeBSD 4. Support could have gone on using make and perl from the ports and perhaps a forced upgrade to xorg. I can understand these as make and perl had been upgraded in 5 and 6, also xorg was the default for 5 and 6. There were however other changes that were not impacting on future developements that were thrown is, as far as I can see, just to make life difficult for people wanting to continue to use FreeBSD 4. Instead of saying use make and perl from the ports it was we are going to cut off all compatability for 4. make index was broken a long time before FreeBSD 4 reached eol. You needed the ports make to actually successfully run make index. Some ports Makefiles were not compatible with FreeBSD 4. Yes. This breakage had been reported along with patches to fix the breakage so that make index would work with the system make from FreeBSD 4. These bugs were never addressed despite being reported months before FreeBSD 4 reached eol. make-20050524 Berkeley make, back-ported to FreeBSD 4.x Mark People with commit access may still make contributions into RELENG_4... Anyways I'm only trying to act within the constraints that I've been given. My mandate does not include upgrading to RELENG_6 so your advice is not immediately useful. What I am interested in hearing is confirmation that the EOL tag works to the extent it was intended to work... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BIND Configuration
Yes, dns-server itself seems to work very well. when I query some public
domains - google.com, yahoo.com -, the result is fine.
but when I put zone files to /etc/namedb/named.conf, the domain is not
resolved.
What is your search path (resolv.conf)? Note dhclient.conf
controls this if you get your addresses via dhcp.
One more thing, /etc/resolv.conf is changed whenever the server reboot
because the server get dynamic IP from ISP.
Assuming DHCP look at dhclient.conf.
e.g.
interface sis0 {
supersede domain-name dv.isc.org isc.org;
prepend domain-name-servers 127.0.0.1;
}
On 6/28/07, ait ^__~ [EMAIL PROTECTED] wrote:
If iget it correct - name resolving don't work at all. Is name resolving
works on dns-server itself? Maybe you want to check configs in your
/etc/resolv.conf file on your dns-server.
2007/6/29, Minseok Choi [EMAIL PROTECTED]:
Hi, I am digging on how to make home server.
The home server is for Wireless AP, file server, samba and LAMP.
The current progress is almost done but I can't solve this problem so
far.
I have 3 PCs. One is home server and the others(A, B) are WinXP.
I have to know A's IP to access A because WinXP got dynamic IP from the
Home
Server.
Is there any way to assign real name instead of IP. I am trying to use
BIND
like the below.
After the configuration, nslookup said the names - bellevue, issaquah
and
sammanish - can't be found.
I'd merely like to access PCs using real name. If you have any idea or
information, please let me know.
/etc/named.conf
zone intranet {
type master;
file master/intranet.zone
}
zone 0.168.192.IN-ADDR.ARPA {
type master;
file master/intranet.rev
}
/etc/master/intranet.zone
@ IN SOA localhost. root.localhost. (
20070628; Serial
3600; Refresh
900 ; Retry
360 ; Expire
3600 ) ; Minimum
IN NS localhost.
bellevue IN A 192.168.0.1
issaquah IN A 192.168.0.2
sammamish IN A 192.168.0.3
/etc/master/intranet.rev
$TTL3600
@ IN SOA localhost. root.localhost . (
20070628; Serial
3600; Refresh
900 ; Retry
360 ; Expire
3600 ) ; Minimum
IN NS localhost.
1 IN PTR bellevue.
2 IN PTR issaquah.
3 IN PTR sammamish.
These should be bellevue.intranet, etc.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: udp fragmentation with pf/ipf
This should be rejected as keep frags is meaningless here. pass out log quick on bge0 proto udp from xxx.xxx.xxx.113/32 to any port = 53 keep state keep frags You need pass in quick from any to any with frag keep frag -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: udp fragmentation with pf/ipf
This should be rejected as keep frags is meaningless here. pass out log quick on bge0 proto udp from xxx.xxx.xxx.113/32 to any port = 53 keep state keep frags You need pass in quick from any to any with frag keep frag The reason is that ip fragments not have next level headers. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD DNS Resolver Issues?
It's a broken load balancer which is returning the parent's SOA record for queries for mail.wtplaw.com. Named correctly rejects this as a garbage response. It also appears to only responds to A/ queries. As for Solaris' host it may/may not be making queries. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.order wrong (ipfw)
On Fri, Mar 16, 2007 at 08:33:01PM -0300, JoaoBR wrote: On Friday 16 March 2007 18:50, Jeremy Chadwick wrote: Okay, imagine this order: 1) Kernel starts 2) Network driver is loaded 3) Link is brought up 4) Interface is configured for IP (manually or via DHCP) 5) Firewall rules (ipfw or pf) are applied Do you realise that between steps #4 and steps #5 there is a small window of time where someone may be able to send packets to your machine and get responses which would normally be blocked by ipfw/pf? nono that is not exactly how it works unless you change ipfw's default behaviour which is deny all from any to an y, nothing goes to this machine because by default everything is blocked until you permit it You're absolutely correct, however your original post seems to have taken many of us by surprise, causing some of us (at least me!) to assume that you've changed the default method to allow. I'm obviously misunderstanding, so I apologise for that, but I hope you can see the reasoning behind my comments with what I knew at the time. :) ipfw needs to be before networking or router discovery fails for IPv6. http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/108589 -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
