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 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 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=28943 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=8843 mtu 1500
inet6 fe80::209:5bff:fe1e:e13e%sis0 prefixlen 64 scopeid 0x2
lo0: flags=8049 mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
gif0: flags=8051 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=1001 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 <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 <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 <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 <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: 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" 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: Installworld and /usr/include/*.h modification times
In message , Kimmo Paasiala writes: > On Fri, Jun 1, 2012 at 8:45 PM, Lowell Gilbert > wrote: > > Kimmo Paasiala 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 , "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"
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: 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"
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: 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 article<4d0c49a2.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: 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: /sbin/reboot
In message , Adam Vande More writes: > On Fri, Dec 10, 2010 at 12:03 AM, Kevin Oberman 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: /sbin/reboot
In message , 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: 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 > > wrote: > >>>>> On 27/08/2010 09:28, Bernhard Schmidt wrote: > >>>>>> On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey > >>> > >>> 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 , "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 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 > > To: > > > > 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 - > > > > > >- Transcript of session follows - > > ... while talking to thuis.klop.ws.: > >>>> RCPT To: > > <<< 554 5.7.1 : Relay access denied > > 554 ... 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 , Dan N
aumov writes:
> On Sun, Jan 24, 2010 at 5:29 PM, John 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 wrote=
> :
> >> > On Fri, Jan 22, 2010 at 6:12 AM, Thomas K. 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 s
Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop
In message , 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 { } while (0)" and "{ } ((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: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop
n 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)
>
> --i616tqyc3hrkKsk2
> Content-Type: application/pgp-signature
> Content-Disposition: inline
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (FreeBSD)
>
> iEYEARECAAYFAksL/P4ACgkQC3+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
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: [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=8049 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=8843 metric 0 mtu 1500
> > > options=389b UCAST,WOL_MCAST,WOL_MAGIC>
> > > ether 00:e0:f4:19:e9:d2
> > > media: Ethernet autoselect (100baseTX )
> > > status: active
> > >lo0: flags=8049 metric 0 mtu 16384
> > >pflog0: flags=141 metric 0 mtu 33204
> > >lo252: flags=8049 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 : > > 2009/7/19 Romain Tarti=E8re : > >> 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 , 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 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=3D"YES" > named_program=3D"/usr/local/sbin/named" # path to named, if you want a = > different one. > named_flags=3D"-c named.conf" > named_uid=3D"bind"# User to run named as > named_chrootdir=3D"/var/named"# Chroot directory (or "" not to = > auto-chroot it) > named_chroot_autoupdate=3D"YES" # Automatically install/update = > chrooted > # components of named. See = > /etc/rc.d/named. > named_symlink_enable=3D"YES" # 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: 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: 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: 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: 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
> --==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
> 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: 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 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: 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 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: 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 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: 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 -- 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?
> 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
> does mean "integrating IPv6 into a production network appears to be > painful". Hence, more animosity towards it by those who don't > understand it. What can I say, short sighted employers. > And last but not least: > > * I don't like incorporating "stuff" into my kernel, my utilities, or > my systems in general which I do not use. I don't want to see an IPv6 > address on my machines or my network. Why? It's about minimalism. I > would gladly "embrace" IPv6 if I had reasons to, but I've none, > therefore I do not. > > Sufficient? > > -- > | Jeremy Chadwick jdc 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 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 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: 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: 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 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 { 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?
> > > icarus# ifconfig lo0 inet 127.0.0.2 netmask 255.255.255.255 alias > > icarus# ifconfig lo0 > > lo0: flags=8049 metric 0 mtu 16384 > >inet 127.0.0.1 netmask 0xff00 > >inet 127.0.0.2 netmask 0x > > icarus# ping 127.0.0.2 > > PING 127.0.0.2 (127.0.0.2): 56 data bytes > > 64 bytes from 127.0.0.2: icmp_seq=0 ttl=64 time=0.022 ms > > 64 bytes from 127.0.0.2: icmp_seq=1 ttl=64 time=0.012 ms > > ^C > > --- 127.0.0.2 ping statistics --- > > 2 packets transmitted, 2 packets received, 0.0% packet loss > > round-trip min/avg/max/stddev = 0.012/0.017/0.022/0.005 ms > > > > > > -- > > | 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]" > > > > > > -- > 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: 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: 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: 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 " repeated until
>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: 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 " repeated until 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: 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
> 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: 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
> --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
> --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=3D8943 mtu=20 > 1500 > options=3Db > 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: 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
> 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: 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: 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?
> 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?
> 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?
> 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:
> > I 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
> 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: 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: 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: 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: > >> > >> 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: 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: 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 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: 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: 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 Saturday 17 March 2007 03:58, Mark Andrews wrote: > > > > > 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 > > > > > as default any network connection will fail so long as you do not permit it > > If rtsol fails or is called to early it is an rtsol problem and not an ipfw > problem I guess > > as another example, what if you set a ifconfig_nic0="inet hostname" instead o > f > IP address and this hostname is not in /etc/hosts and ipfw is still not up > and named is far away to start, then, according to your idea we need to start If you do that then the address must be in /etc/hosts. > named and ipfw before netif? ip6fw is before networking. ipfw is supposed to be taking over from ip6fw. ipfw and ip6wf should be started at a similar time. rtsol is approximately the equivalent to DHCP. The machine is requesting a address from the network. It doesn't matter if it is a router or a DHCP server that is suppling the address. DHCP only works because it bypasses the firefall. Mark > -- > > João > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. > Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br > ___ > 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]"
