Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/08/2012 23:16, Avleen Vig wrote: On Sun, Jul 8, 2012 at 10:51 PM, Doug Barton do...@freebsd.org wrote: On 07/08/2012 22:43, Avleen Vig wrote: It would be silly not to keep bind-tools in base. Sounds easy, but not so much in practice. Keeping any of the code doesn't solve the problem of the release cycles not syncing up. And for the vast majority of users needs the tools we will import will be more than adequate. The question I keep asking myself is: Is this best for the users? Carrying BIND code in the base that is past EOL is not good for the users, period. Everything else we're discussing is an implementation detail. Linux has `nscd` which is a nice caching resolver, but most distributions still carry bind-tools in the default install. A) You're wrong about most. and B) The Linux distros have a default set of packages. There is no base like there is in FreeBSD. (Thus, your analogy is flawed.) That said, I still believe that our idea of what should, and should not be, in the base system is seriously flawed, and needs to be completely redone. But that's never going to happen, so I'm trying to work with what we've got. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/09/2012 00:34, Avleen Vig wrote: On Sun, Jul 8, 2012 at 11:26 PM, Doug Barton do...@freebsd.org wrote: On 07/08/2012 23:16, Avleen Vig wrote: On Sun, Jul 8, 2012 at 10:51 PM, Doug Barton do...@freebsd.org wrote: On 07/08/2012 22:43, Avleen Vig wrote: It would be silly not to keep bind-tools in base. Sounds easy, but not so much in practice. Keeping any of the code doesn't solve the problem of the release cycles not syncing up. And for the vast majority of users needs the tools we will import will be more than adequate. The question I keep asking myself is: Is this best for the users? Carrying BIND code in the base that is past EOL is not good for the users, period. Everything else we're discussing is an implementation detail. I think the everything else we're discussing is an implementation detail is the part we'll have a problem with. No doubt there will be some bumps in the road. That's why it is going to be done in -current before 10-RELEASE, so that the bugs can be worked out. Although Garrett's reply to my email makes sense too. That said, I still believe that our idea of what should, and should not be, in the base system is seriously flawed, and needs to be completely redone. But that's never going to happen, so I'm trying to work with what we've got. Agreed. The idea of a minimally functional system itself might be flawed. No, there are 2 questions. First, What is a minimally functional system? and second, How do we provide it? Answering those questions is beyond the scope of this thread. Do you consider having `dig` and `host` essential in a minimally functioning system? I do. It's pretty f'king hard to resolve problems with installing the bind-utils port, if you don't know how to test your DNS :-) No one has said that we're going to leave the base without any tools. Please actually read the entire thread before commenting further. Yes, I'm going to be a stickler and say that having EOL code in base isn't the end of the world. Yours is a minority opinion. If there's a security vulnerability, sure, I understand that it might suck without support from ISC to patch dig/host/nslookup, but when was the last time that happened? Those binaries are just wrappers to the BIND libs, which are upgraded rather often when security vulnerabilities are found. Up to this point I've tried to respond to your questions in the hopes that answering them will serve to elucidate some of the details behind what's going on here. At this point though I'm starting to repeat myself. So if you have further questions I'd suggest that you read the entire thread so far, and then do some research on your own to try and understand the problem better. After that, if you still disagree, voicing your concerns when Dag-Erling has had a chance to get involved is probably your best bet. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 7/9/12 12:44 AM, Dan Lukes wrote: On 07/08/12 23:55, Doug Barton: On 07/08/2012 07:41, Dan Lukes wrote: ... Sorry, you're not understanding what is being proposed. Specifically you're confusing the system stub resolver (the bit that's compiled into libc, and used by binaries) and the resolving name server (BIND). No one is proposing to replace the stub. libc stub resolver is BIND code based, so I assumed that arguments against BIND apply to it as well. I'm happy it's not true. In my humble opinion, no resolving name server need to be part of base at all. We have no DHCP, VPN, RADIUS, WWW, ... server in the base as well. Thank you for clarifying. Dan Whereas you don't need a DHCP, VPN, RADIUS or WWW server to do *anything at all* with your newly installed BSD machine, you sort of need a DNS resolver... I for one am not going to use a 3rd party resolver, even if only to download the ports' source code for BIND, so I'm happy it's provided in the base. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound
Avleen Vig avl...@gmail.com writes: It would be silly not to keep bind-tools in base. `host` and `dig` are very standard tools most people expect to be available in base, just as they are in the base/core/whatever of other operating systems. We should definitely have an implementation of host(1), but dig(1) is not nearly as widely used, and ldns's drill(1) supports the same command-line syntax for the most common operations. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound
Avleen Vig avl...@gmail.com writes: As bind-tools and BIND (the resolver) as separate, why not just leave bind-tools in base? They'll work happily with unbound. The bind-tools (host, dig, nslookup) are command-line frontends for the resolver. Perhaps what you are trying to say is that they are separate from the authoritative nameserver (named). Yes, they are, but they have a *lot* of code in common. In fact, *most* of the code in BIND is common code shared between named, dig etc. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound
Gabor Kovesdan ga...@freebsd.org writes: Other than the functionality, when we replace something, it is also important to do some benchmarks and assure that the performance is not reasonably worse. Some time back I committed the error of not carefully pass this requirement with BSD grep but so far it seems it went fine with the recent BSD sort change. It would be nice to also ensure this with the unbound change if it really happens. What sort of benchmarks do you envision? Unlike named, unbound is intended to serve only one client (localhost) or a small number of clients (a SOHO). With that kind of load, one could be ten times slower than the other and you wouldn't notice, because other factors, like network latency, completely dwarf the time the nameserver itself spends servicing a request. (note that I fully expect unbound to hold its own on corporate networks with thousands of clients, but I doubt my boss is going to let me run performance comparisons on the university's network) DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On Sun, Jul 8, 2012 at 10:29 AM, Doug Barton do...@freebsd.org wrote: Unbound has different policies and release schedules that are more in line with ours. So in the short term (as in, the next few years) we're better off with unbound in the base. Where is there information about this / what is their support? When I looked at their website I found nothing about security support, branch handling etc. and nobody has replied to that part in these threads (unless I missed it - I just rescanned thread without seeing a reply). -- Simon L. B. Nielsen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On Sat, Jul 7, 2012 at 4:38 PM, Doug Barton do...@freebsd.org wrote: On 07/07/2012 16:33, Garrett Wollman wrote: On Sat, 07 Jul 2012 16:17:53 -0700, Doug Barton do...@freebsd.org said: BIND in the base today comes with a full-featured local resolver configuration, which I'm confident that Dag-Erling can do for unbound (and which I would be glad to assist with if needed). Other than that, what integration are you concerned about? The utilities (specifically host(1) and dig(1)) are the only user-visible interfaces I care about. I don't see any need for there to be an authoritative name server in the base system. So long as the resolver works properly and does DNSsec validation I addressed the utils in a previous message, but once more ... ldns (a dependency of unbound) comes with drill, which is a dig-alike tool. I'd like to see us produce a host-alike based on ldns as well, which should be a pretty simple junior hacker task for a motivated group. If those don't do it for you, ports/dns/bind-tools already exists. It would be silly not to keep bind-tools in base. `host` and `dig` are very standard tools most people expect to be available in base, just as they are in the base/core/whatever of other operating systems. I'm all for writing other tools based on ldns, but now you're talking about doing things that create extra work for me, the end user, for something that gives me very little gain (if any). I either have to install bind-tools or rewrite scripts. And what do I get? Nothing I really care about. Think about the benefit to the end user before making such decisions. Especially if you're talking about taking away something that is already there and taken for granted. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On Sun, Jul 8, 2012 at 2:39 PM, Doug Barton do...@freebsd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/08/2012 10:10, Jason Hellenthal wrote: From first impression it seems that drill(1) has a syntax that leaves something to be desired like the eased use of host or dig. So once again, if you need the exact capabilities of ISC host and dig, install them from the port. As bind-tools and BIND (the resolver) as separate, why not just leave bind-tools in base? They'll work happily with unbound. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On Sun, Jul 8, 2012 at 10:51 PM, Doug Barton do...@freebsd.org wrote: On 07/08/2012 22:43, Avleen Vig wrote: It would be silly not to keep bind-tools in base. Sounds easy, but not so much in practice. Keeping any of the code doesn't solve the problem of the release cycles not syncing up. And for the vast majority of users needs the tools we will import will be more than adequate. The question I keep asking myself is: Is this best for the users? I can't convince myself that it is, at the moment. While I completely agree with you reasons, and I do think that in an ideal way they'd be good, I'm just not sure they are the best thing to do for users. Linux has `nscd` which is a nice caching resolver, but most distributions still carry bind-tools in the default install. Enough people expect the tools to be there, that getting rid of them for almost any reason seems like a bad idea for low benefit. I could care less about the resolver daemon itself, I agree with what you're saying and I don't think most end users will care about that. But getting rid of dig and host in base would be bad. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On Sun, 8 Jul 2012 23:16:04 -0700, Avleen Vig avl...@gmail.com said: I could care less about the resolver daemon itself, I agree with what you're saying and I don't think most end users will care about that. But getting rid of dig and host in base would be bad. I don't think it's as bad as you suggest, although I do think they we would likely get a few black eyes from just the same. After all, as Doug says, people can just install the bind-tools package. So long as there is *a* tool in the base, even if it's not the two we all are used to, that's sufficient for the purpose of doing enough troubleshooting to get package installs working. I think the embedded people have a better argument, but that's probably still not strong enough versus the benefits of making this change. (The black eyes will come from reviewers saying WTF, FreeBSD! How can you not have host and dig?! without bothering to read the release notes or investigate ports that they might want to have installed. The fact that this same crowd always installs sudo from ports will not prevent them from being astonished. I think there's a good case to be made for having a set of packages that are installed by default by the installer unless you disable it -- in my lab, we'll be wanting to install puppet -- and bind-tools is probably one of them.) -GAWollman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On Sun, Jul 8, 2012 at 11:26 PM, Doug Barton do...@freebsd.org wrote: On 07/08/2012 23:16, Avleen Vig wrote: On Sun, Jul 8, 2012 at 10:51 PM, Doug Barton do...@freebsd.org wrote: On 07/08/2012 22:43, Avleen Vig wrote: It would be silly not to keep bind-tools in base. Sounds easy, but not so much in practice. Keeping any of the code doesn't solve the problem of the release cycles not syncing up. And for the vast majority of users needs the tools we will import will be more than adequate. The question I keep asking myself is: Is this best for the users? Carrying BIND code in the base that is past EOL is not good for the users, period. Everything else we're discussing is an implementation detail. I think the everything else we're discussing is an implementation detail is the part we'll have a problem with. Although Garrett's reply to my email makes sense too. Linux has `nscd` which is a nice caching resolver, but most distributions still carry bind-tools in the default install. A) You're wrong about most. and B) The Linux distros have a default set of packages. There is no base like there is in FreeBSD. (Thus, your analogy is flawed.) That's not *really* true, there is a base like FreeBSD, but what we consider core userland tools like `ls`, come in a package (coreutils). That said, I still believe that our idea of what should, and should not be, in the base system is seriously flawed, and needs to be completely redone. But that's never going to happen, so I'm trying to work with what we've got. Agreed. The idea of a minimally functional system itself might be flawed. Do you consider having `dig` and `host` essential in a minimally functioning system? I do. It's pretty f'king hard to resolve problems with installing the bind-utils port, if you don't know how to test your DNS :-) The issue is also one of barrier-to-entry. By removing `dig` and `host`, I think we're making things unnecessarily more difficult for people who don't *know* FreeBSD. `dig` and `host` a universally standard tools for doing DNS lookups. Taking them away in base to replace them with something else just seems like something that won't really *help* users. Yes, I'm going to be a stickler and say that having EOL code in base isn't the end of the world. It's not ideal, but really.. what is it breaking? If there's a security vulnerability, sure, I understand that it might suck without support from ISC to patch dig/host/nslookup, but when was the last time that happened? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On Monday 09 July 2012 09:34:34 Avleen Vig wrote: The issue is also one of barrier-to-entry. By removing `dig` and `host`, I think we're making things unnecessarily more difficult for people who don't *know* FreeBSD. `dig` and `host` a universally standard tools for doing DNS lookups. Taking them away in base to replace them with something else just seems like something that won't really *help* users. Yes. So we should change the base system so that by default it does a database lookup whenever you type an unrecognised command - to lower the barrier to entry. We should also change the base system to remove the most commonly used tools for doing DNS lookups, to what was the reason again? I suppose at least those arguing for both these changes can argue that one mitigates the non-POLA effect of the other Jonathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 9 Jul 2012, at 08:34, Avleen Vig wrote: Agreed. The idea of a minimally functional system itself might be flawed. Do you consider having `dig` and `host` essential in a minimally functioning system? I do. It's pretty f'king hard to resolve problems with installing the bind-utils port, if you don't know how to test your DNS :-) The issue is also one of barrier-to-entry. By removing `dig` and `host`, I think we're making things unnecessarily more difficult for people who don't *know* FreeBSD. `dig` and `host` a universally standard tools for doing DNS lookups. Taking them away in base to replace them with something else just seems like something that won't really *help* users. Indeed, 'dig' and 'host' must be present and working as expected in a minimally installed system. - Mark ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Interfacing devices with multiple parents within newbus
On Friday, July 06, 2012 4:45:55 pm Arnaud Lacombe wrote: Hi, On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore free...@damnhippie.dyndns.org wrote: On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote: Hi, On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe lacom...@gmail.com wrote: That's neither correct nor robust in a couple of way: 1) you have no guarantee a device unit will always give you the same resource. this raises the following question: how can a device, today, figure out which parent in a given devclass would give it access to resources it needs. Say, you have gpiobus0 provided by a superio and gpiobus1 provided by the chipset and a LED on the chipset's GPIO. Now, say gpiobus0 attachment is conditional to some BIOS setting. How can you tell gpioled(4) to attach on the chipset provided GPIO without hardcoding unit number either way ? AFAIK, you can not. Even hints provided layout description is defeated. Each device in a given devclass need to have a set of unique attribute to allow a child to distinguish it from other potential parent in the same devclass... - Arnaud Talking about a child being unable to choose the correct parent seems to indicate that this whole problem is turned upside-down somehow; children don't choose their parents. actually, I think I was wrong, I thought device were attached to a devclass, but they are truly attached to a given device. My mistake. Just blue-sky dreaming here on the fly... what we really have is a resource-management problem. A device comes along that needs a GPIO resource, how does it find and use that resource? Well, we have a resource manager, could that help somehow? Could a driver that provides access to GPIO somehow register its availability so that another driver can find and access it? The resource may be a callable interface, it doesn't really matter, I'm just wondering if the current rman stuff could be leveraged to help make the connection between unrelated devices. I think that implies that there would have to be something near the root of the hiearchy willing to be the owner/manager of dynamic resources. AFAIR, rman is mostly there to manage memory vs. i/o mapped resources. The more I think about it, the more FTD is the answer. The open question now being how to map a flexible device structure (FTD) to a less flexible structure (Newbus) :/ Note that IRQs are also managed in rman. However, that is a complicated beast. Generally there is some sideband way for interrupt controllers to register their available interrupt pins with the platform's nexus driver (often the actual PIC is not managed via new-bus). You then need something else to let a given device know which interrupt pin it wants (e.g. PCI interrupt routing). However, you could make a similar approach work for GPIO perhaps, where devices make GPIO pins available to a rman that other devices then allocate from. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: newbus' ivar's limitation..
On Monday, July 09, 2012 12:39:03 am Warner Losh wrote:
On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote:
Hi,
On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh i...@bsdimp.com wrote:
On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.
There's one pointer for the ivars. The bus code gets to determine what
the ivar looks like, because the interface is totally private to the bus. So
long as it returns the right thing for any key that's presented, it doesn't
matter quite how things are done.
So I'm not sure I understand what you are saying here.
The problem, more basically, is that the ivar keys are not unique.
Currently, there's no bits used in the key to define the values to be non-
overlapping. For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
};
We could easily reserve the upper 16-bits of this field to be that key.
This value could then be used to differentiate them. But this wouldn't scale
too well. Given that there's only about a dozen or two in the tree, that's
right at the moment, it wouldn't be hard to do something like:
enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16
and the above could be changed to:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
};
and then we'd have an unambiguous key, and the bus could easily implement
multiple interfaces.
but then again, most of the existing interfaces in the kernel are
mutually exclusive, so you could implement this just for your new interfaces.
ok, I think I got it now. You and I are exactly saying the same thing,
just in different terms; there is no way to currently specify multiple
independent (/overlapping) ivars in a child...
There's no way to support overlapping IVAR keys, yes. However, if you are
designing the ivars for multiple inheritance, then you'll need to make them
non-overlapping. Thankfully, this is trivial to do.
Also, I think we should do this in general. We already have one example (e.g.
ACPI IVARs start at 100 so that things like the ACPI PCI bus driver can
provide both ACPI and PCI IVARs to child devices). I think we should assign
each bus it's own IVAR range. It would make it easier to determine if a
specific IVAR is event supported. Certainly I think ISA and PCI at a minimum
should be changed to start at, say, 200 and 300.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On Mon, Jul 9, 2012 at 12:34 AM, Avleen Vig avl...@gmail.com wrote: [snip] The issue is also one of barrier-to-entry. By removing `dig` and `host`, I think we're making things unnecessarily more difficult for people who don't *know* FreeBSD. `dig` and `host` a universally standard tools for doing DNS lookups. Taking them away in base to replace them with something else just seems like something that won't really *help* users. [snip] One reason I'd like to see these standard tools be replaced with something better is that their output sucks for use in any kind of automation (unlike e.g. some of the the tools that ship with djbdns). Jos -- Jos Backus jos at catnook.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On Mon, Jul 09, 2012 at 09:42:43AM -0700, Jos Backus wrote: On Mon, Jul 9, 2012 at 12:34 AM, Avleen Vig avl...@gmail.com wrote: [snip] The issue is also one of barrier-to-entry. By removing `dig` and `host`, I think we're making things unnecessarily more difficult for people who don't *know* FreeBSD. `dig` and `host` a universally standard tools for doing DNS lookups. Taking them away in base to replace them with something else just seems like something that won't really *help* users. [snip] One reason I'd like to see these standard tools be replaced with something better is that their output sucks for use in any kind of automation (unlike e.g. some of the the tools that ship with djbdns). Where there is a will there is a way... usually boils down to the administrators understanding and use of system utilities to get the results they want. -- - (2^(N-1)) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: distinguish between Maxmem, realmem, physmem
Thanks Kim. That's very helpful. One more question, to get teh RAM of the system, is the way r190599 reliable? Could we trust env variable to get memory reading from bios? If I would like to calculate the RAM from totalmem = physmem 12 + reserve_memory+ msgbuff_size How can I get size of reserve_memory, i belive msgbuff_size is 65536? THANKS -- View this message in context: http://freebsd.1045724.n5.nabble.com/distinguish-between-Maxmem-realmem-physmem-tp5722282p5725463.html Sent from the freebsd-hackers mailing list archive at Nabble.com. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
dtraceall.ko with old nfsclient
Ran into some symbol errors with the dtraceall module when using the *old* nfs client. I think that this is more or less the right thing to do, but I'm not sure. --- //depot/yahoo/ybsd_9/src/sys/modules/dtrace/dtraceall/dtraceall.c 2011-11-02 23:46:55.0 +++ /home/seanbru/dtrace_9/src/sys/modules/dtrace/dtraceall/dtraceall.c 2011-11-02 23:46:55.0 @@ -66,8 +66,11 @@ MODULE_DEPEND(dtraceall, opensolaris, 1, 1, 1); MODULE_DEPEND(dtraceall, dtrace, 1, 1, 1); MODULE_DEPEND(dtraceall, dtmalloc, 1, 1, 1); +#if defined (NFSCL) MODULE_DEPEND(dtraceall, dtnfscl, 1, 1, 1); +#else /* defined (NFSCLIENT) */ MODULE_DEPEND(dtraceall, dtnfsclient, 1, 1, 1); +#endif #if defined(__amd64__) || defined(__i386__) MODULE_DEPEND(dtraceall, fbt, 1, 1, 1); MODULE_DEPEND(dtraceall, fasttrap, 1, 1, 1); ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Better ldns docs? (Was: bikeshedding about BIND)
On Sun, Jul 08, 2012 at 02:21:46 -0700 , Doug Barton wrote: That's an implementation issue, and is easily handled with drill, or the host-like program we all agree is a really-nice-to-have. About that: as I said elsewhere in one of these threads (I want my bikeshed clear and chartreuse at the same time, thank you), I decided to give this a try. However I'm finding the Doxygen autogenerated documentation to be less than useful. I'd really appreciate a task-oriented set of documentation. The design guide helps somewhat but I'm still missing a good set of docs for how things fit together. I suppose you could say well volunteered to that, too, but I'm not sure if the docs will get finished in time for a good CLI client for 10-RELEASE. -- Thanks and best regards, Chris Nehren pgpjqnyBdJSbw.pgp Description: PGP signature
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 2012-Jul-09 14:15:13 +0200, in freebsd-security, Andrej (Andy) Brodnik and...@brodnik.org wrote: Excuse my ignorance - but is there a how-to paper on transition from bind to unbound for SOHO? In particular, if unbound has no authoritative server capabilities, what suggestions are there for handling the private hosts in a SOHO environment? -- Peter Jeremy pgpJAciudHfKN.pgp Description: PGP signature
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/09/2012 13:47, Peter Jeremy wrote: On 2012-Jul-09 14:15:13 +0200, in freebsd-security, Andrej (Andy) Brodnik and...@brodnik.org wrote: Excuse my ignorance - but is there a how-to paper on transition from bind to unbound for SOHO? You don't need to transition if you don't want to. Just install BIND from the ports. In particular, if unbound has no authoritative server capabilities, what suggestions are there for handling the private hosts in a SOHO environment? Stub and/or forward zones. The unbound docs have more information. Doug - -- This .signature sanitized for your protection -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJP+0R/AAoJEFzGhvEaGryECuQIAM2CtwjuYZPpQHYojU93mF7g ZLmTqmo8cdunpRUc66hHEirqnmnZ58LkosOugbuTgNvWAB9H2NOo25rFKkft3k0q S+5hSqS442NNvEYrsOlBhdPlP/cEpK36Mt24o3UlB1JVDjX0oj3BxXBc6BY08zHI 6/vCr74+SBHrg8k5yOhLpbgI5sEENhEAKNQY/6XSUmQlWzOPTMVEehp2Xon+llbf m/T5vkjitLBSveG7+xwFT4gCMgI1S2eJcFE/rmgmLYI9iqoUkp5uO/eSZQBi12Qa EIHKIPwp1eioSdrtPqZTuqLaPripJ+ewhveL126aXFVsKToskk9HaFRQr0TzMac= =Ojll -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/09/2012 06:33, Jonathan McKeown wrote: On Monday 09 July 2012 09:34:34 Avleen Vig wrote: The issue is also one of barrier-to-entry. By removing `dig` and `host`, I think we're making things unnecessarily more difficult for people who don't *know* FreeBSD. `dig` and `host` a universally standard tools for doing DNS lookups. Taking them away in base to replace them with something else just seems like something that won't really *help* users. Yes. So we should change the base system so that by default it does a database lookup whenever you type an unrecognised command - to lower the barrier to entry. Right. We should also change the base system to remove the most commonly used tools for doing DNS lookups, to what was the reason again? It's been covered at length in this thread. We get it, change is hard. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/09/2012 06:45, Mark Blackman wrote: Indeed, 'dig' and 'host' must be present and working as expected in a minimally installed system. So if you don't like the versions that get imported, install bind-tools from ports. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: dtraceall.ko with old nfsclient
on 09/07/2012 22:49 Sean Bruno said the following: Ran into some symbol errors with the dtraceall module when using the *old* nfs client. I think that this is more or less the right thing to do, but I'm not sure. --- //depot/yahoo/ybsd_9/src/sys/modules/dtrace/dtraceall/dtraceall.c 2011-11-02 23:46:55.0 +++ /home/seanbru/dtrace_9/src/sys/modules/dtrace/dtraceall/dtraceall.c 2011-11-02 23:46:55.0 @@ -66,8 +66,11 @@ MODULE_DEPEND(dtraceall, opensolaris, 1, 1, 1); MODULE_DEPEND(dtraceall, dtrace, 1, 1, 1); MODULE_DEPEND(dtraceall, dtmalloc, 1, 1, 1); +#if defined (NFSCL) MODULE_DEPEND(dtraceall, dtnfscl, 1, 1, 1); +#else /* defined (NFSCLIENT) */ MODULE_DEPEND(dtraceall, dtnfsclient, 1, 1, 1); +#endif #if defined(__amd64__) || defined(__i386__) MODULE_DEPEND(dtraceall, fbt, 1, 1, 1); MODULE_DEPEND(dtraceall, fasttrap, 1, 1, 1); Just to add some noise to the signal - my personal opinion is that nfs support doesn't have to be in dtraceall. Maybe in something all-er :-) -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 9 Jul 2012, at 22:01, Doug Barton wrote: On 07/09/2012 06:45, Mark Blackman wrote: Indeed, 'dig' and 'host' must be present and working as expected in a minimally installed system. So if you don't like the versions that get imported, install bind-tools from ports. my DNS resolution is broken, so my ports can't download any tarballs. In this case, I reach for dig to see which part of the DNS resolution chain is failing me. At the bare minimum, 'dig' should be an alias for 'drill', which I have to say isn't working brilliantly for me on OS X. It suggests I use '-t' and then keeps suggesting I use '-t' even when I do use it. drill feels a bit rough around the edges to me. - Mark ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound
Mark Blackman m...@exonetric.com writes: my DNS resolution is broken, so my ports can't download any tarballs. In this case, I reach for dig to see which part of the DNS resolution chain is failing me. At the bare minimum, 'dig' should be an alias for 'drill', which I have to say isn't working brilliantly for me on OS X. It suggests I use '-t' and then keeps suggesting I use '-t' even when I do use it. drill feels a bit rough around the edges to me. This reminds me of the (probably apocryphal) American grade school teacher who complained that the metric system was so inexact; for instance, a meter is _approximately_ a yard, a kilometer is _approximately_ two thirds of a kilometer, etc. By which I mean, of course, that you are blaming drill not for its own shortcomings, but for those of the wrapper you use to _approximate_ dig with drill. The -t option doesn't mean the same for drill as for dig. A proper dig wrapper for drill would have to translate one to the other. However, you should never need the -t option when using dig; I suspect that it exists only for people who are so used to host that they want to use the same command line except for s/host/dig/. Instead of 'dig -t soa des.no', you should use 'dig des.no soa'. The syntax is dig [@server] name [type] [class] I'm not sure why it supports a class argument, since as far as I know, the only class still in use is IN. In the most common case, dig and drill are nearly identical; the command line is exactly the same (except for s/dig/drill/), and the output nearly so - drill doesn't print a question section. If that's a problem for you, it's easily fixed. % dig @ns.des.no des.no soa ; DiG 9.6.-ESV-R5-P1 @ns.des.no des.no soa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 47226 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; QUESTION SECTION: ;des.no.IN SOA ;; ANSWER SECTION: des.no. 3600IN SOA ns.des.no. hostmaster.des.no. 2012042401 3600 900 360 3600 ;; AUTHORITY SECTION: des.no. 3600IN NS ns.des.no. des.no. 3600IN NS ns.hyp.net. ;; ADDITIONAL SECTION: ns.des.no. 3600IN A 194.63.250.121 ;; Query time: 0 msec ;; SERVER: 194.63.250.121#53(194.63.250.121) ;; WHEN: Mon Jul 9 23:22:05 2012 ;; MSG SIZE rcvd: 128 % drill @ns.des.no des.no soa ;; -HEADER- opcode: QUERY, rcode: NOERROR, id: 61642 ;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; QUESTION SECTION: ;; des.no. IN SOA ;; ANSWER SECTION: des.no. 3600IN SOA ns.des.no. hostmaster.des.no. 2012042401 3600 900 360 3600 ;; AUTHORITY SECTION: des.no. 3600IN NS ns.des.no. des.no. 3600IN NS ns.hyp.net. ;; ADDITIONAL SECTION: ns.des.no. 3600IN A 194.63.250.121 ;; Query time: 0 msec ;; SERVER: 194.63.250.121 ;; WHEN: Mon Jul 9 23:22:23 2012 ;; MSG SIZE rcvd: 128 DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound
On 9 Jul 2012, at 22:37, Dag-Erling Smørgrav wrote: Mark Blackman m...@exonetric.com writes: my DNS resolution is broken, so my ports can't download any tarballs. In this case, I reach for dig to see which part of the DNS resolution chain is failing me. At the bare minimum, 'dig' should be an alias for 'drill', which I have to say isn't working brilliantly for me on OS X. It suggests I use '-t' and then keeps suggesting I use '-t' even when I do use it. drill feels a bit rough around the edges to me. This reminds me of the (probably apocryphal) American grade school teacher who complained that the metric system was so inexact; for instance, a meter is _approximately_ a yard, a kilometer is _approximately_ two thirds of a kilometer, etc. By which I mean, of course, that you are blaming drill not for its own shortcomings, but for those of the wrapper you use to _approximate_ dig with drill. The -t option doesn't mean the same for drill as for dig. A proper dig wrapper for drill would have to translate one to the other. However, you should never need the -t option when using dig; I suspect that it exists only for people who are so used to host that they want to use the same command line except for s/host/dig/. I never use '-t' with dig. drill *told* me I should use '-t' then completely failed to acknowledge I had done so. Marks-Macbook% drill -t www.google.com ;; -HEADER- opcode: QUERY, rcode: NOERROR, id: 14583 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; www.google.com. IN A ;; ANSWER SECTION: www.google.com. 44089 IN CNAME www.l.google.com. www.l.google.com. 147 IN A 173.194.67.106 www.l.google.com. 147 IN A 173.194.67.147 www.l.google.com. 147 IN A 173.194.67.104 www.l.google.com. 147 IN A 173.194.67.105 www.l.google.com. 147 IN A 173.194.67.103 www.l.google.com. 147 IN A 173.194.67.99 ;; AUTHORITY SECTION: ;; ADDITIONAL SECTION: ;; Query time: 34 msec ;; SERVER: 178.250.72.130 ;; WHEN: Mon Jul 9 22:46:13 2012 ;; MSG SIZE rcvd: 148 ;; WARNING: The answer packet was truncated; you might want to ;; query again with TCP (-t argument), or EDNS0 (-b for buffer size) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound
Mark Blackman m...@exonetric.com writes: I never use '-t' with dig. drill *told* me I should use '-t' then completely failed to acknowledge I had done so. Marks-Macbook% drill -t www.google.com [...] ;; WARNING: The answer packet was truncated; you might want to ;; query again with TCP (-t argument), or EDNS0 (-b for buffer size) So you got a truncated response and used -t, it didn't help, and drill printed the boilerplate warning message that it always prints when it gets a truncated response. I don't know about you, but I would call that a cosmetic nit. Unless, of course, you had tcpdump running while you did this and it turns out that drill sent a UDP request in spite of -t? It works fine (i.e. it uses UDP by default, and TCP when asked to) for me. I even tried the same nameserver you used, and was very surprised to get an answer. If you know the people who run it, you might let them know that it is inadvisable to process recursive queries from outside their own network. FWIW, the reply I got was not truncated. Perhaps there is a transparent DNS proxy somewhere between you and 178.250.72.130 - quite common with broadband CPE. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound
On 9 Jul 2012, at 23:01, Dag-Erling Smørgrav wrote: Mark Blackman m...@exonetric.com writes: I never use '-t' with dig. drill *told* me I should use '-t' then completely failed to acknowledge I had done so. Marks-Macbook% drill -t www.google.com [...] ;; WARNING: The answer packet was truncated; you might want to ;; query again with TCP (-t argument), or EDNS0 (-b for buffer size) So you got a truncated response and used -t, it didn't help, and drill printed the boilerplate warning message that it always prints when it gets a truncated response. I don't know about you, but I would call that a cosmetic nit. Unless, of course, you had tcpdump running while you did this and it turns out that drill sent a UDP request in spite of -t? It works fine (i.e. it uses UDP by default, and TCP when asked to) for me. Yes, I worked out it was boilerplate for the general condition. A cosmetic nit that makes me do a double-take on my first usage strikes me as rough around the edges. YMMV. drill certainly looks like a drop-in replacement for the common case as you suggest. But if it's not called 'dig' and I've never heard of 'drill', I'm unlikely to reach for 'drill', hence the alias suggestion. I *had* never heard of 'drill' until this thread came up. FWIW, the reply I got was not truncated. Perhaps there is a transparent DNS proxy somewhere between you and 178.250.72.130 - quite common with broadband CPE. I have detected there is some kind of stealth DNS interception at work in the past, although I think it's more central than the CPE. Mark___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound
Mark Blackman m...@exonetric.com writes: drill certainly looks like a drop-in replacement for the common case as you suggest. But if it's not called 'dig' and I've never heard of 'drill', I'm unlikely to reach for 'drill', hence the alias suggestion. I *had* never heard of 'drill' until this thread came up. They are sufficiently similar that writing a wrapper that supports a significant subset of dig's command-line option and uses drill as a backend shouldn't take more than an afternoon for a reasonably experienced programmer. I'm not entirely convinced that it is really required, but considering how easy it would be to implement, there's no reason not to. A drop-in replacement for host is, of course, an absolute requirement. As for nslookup... it's been deprecated for a decade. Its only saving grace is that its interactive mode is useful for playing text adventures implemented with DNS TXT records :) DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/09/12 17:01, Doug Barton wrote: On 07/09/2012 06:45, Mark Blackman wrote: Indeed, 'dig' and 'host' must be present and working as expected in a minimally installed system. So if you don't like the versions that get imported, install bind-tools from ports. Doug Doug, you are one of the people whose writings on the FreeBSD lists I most respect. But I think you are wrong about this one aspect of your proposed change. To discover that dig is suddenly not in the base FreeBSD system any more some day would be just about the worst violation of the Principle of Least Astonishment for me in many years. And discovering it just when I'm having trouble downloading packages would be salt in the wound.-- George Mitchell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound 9.1 code freeze?)
Firstly, I should note that I'm not against removing bind from base. I'm merely saying that users are going to need some guidance during the transition. On 2012-Jul-09 13:52:15 -0700, Doug Barton do...@freebsd.org wrote: On 07/09/2012 13:47, Peter Jeremy wrote: On 2012-Jul-09 14:15:13 +0200, in freebsd-security, Andrej (Andy) Brodnik and...@brodnik.org wrote: Excuse my ignorance - but is there a how-to paper on transition from bind to unbound for SOHO? You don't need to transition if you don't want to. Just install BIND from the ports. IMHO, this is a copout. If the default response to anyone asking a question about transitioning is install bind then we might as well leave bind in the base system. As I see it, FreeBSD systems fall roughly into 3 categories: 1) Client systems that need to lookup external DNS servers only. 2) SOHO systems that primarily do external lookups but need to be internally authoritative about their local network. 3) Systems that are primarily DNS servers. The third category is clearly a use ports case - there's no need for the base system to include all the tools necessary to build one of the root nameservers. The base system _must_ handle the first category - and I'll accept advice from dougb@ des@ that unbound is a good choice for this. The issues people seem to have with the change here are the user tools to interface with DNS - currently dig(1), host(1) and nslookup(1) - and des@ has now adequately covered this. I think the majority of the remaining unease in this thread comes from people who administer systems in the second category. I (and I expect lots of other people) use bind for this solely because it is in the base system, not because it is the best tool for the job. In particular, if unbound has no authoritative server capabilities, what suggestions are there for handling the private hosts in a SOHO environment? Stub and/or forward zones. The unbound docs have more information. But unfortunately no tutorial guides. Having looked at the online copy of unbound.conf(5), it appears that unbound _does_ have some limited server capabilities - this wasn't clear in the original proposal. It's not immediately clear to me whether it's adequate for my purposes and, if it isn't, what I should use. This is an area where I expect there will be community input - potentially via the FreeBSD wiki. -- Peter Jeremy pgp6vbMlLvV6G.pgp Description: PGP signature
Re: Replacing BIND with unbound
On 2012-Jul-10 00:40:07 +0200, Dag-Erling Smørgrav d...@des.no wrote: They are sufficiently similar that writing a wrapper that supports a significant subset of dig's command-line option and uses drill as a backend shouldn't take more than an afternoon for a reasonably experienced programmer. I would further suggest that where a dig(1) option isn't emulated, the fallback error message should refer the user to drill(1). As for nslookup... it's been deprecated for a decade. But old fogies might still use it. Can I suggest that something along the lines of the the following be installed as /usr/bin/nslookup: #!/bin/sh echo nslookup is no longer supported. Please see drill(1) or host(1) 2 exit 1 -- Peter Jeremy pgpP08j1bRN4J.pgp Description: PGP signature
Re: Replacing BIND with unbound
On Jul 9, 2012 7:57 PM, Peter Jeremy pe...@rulingia.com wrote: On 2012-Jul-10 00:40:07 +0200, Dag-Erling Smørgrav d...@des.no wrote: They are sufficiently similar that writing a wrapper that supports a significant subset of dig's command-line option and uses drill as a backend shouldn't take more than an afternoon for a reasonably experienced programmer. I would further suggest that where a dig(1) option isn't emulated, the fallback error message should refer the user to drill(1). As for nslookup... it's been deprecated for a decade. But old fogies might still use it. Can I suggest that something along the lines of the the following be installed as /usr/bin/nslookup: #!/bin/sh echo nslookup is no longer supported. Please see drill(1) or host(1) 2 exit 1 This is a much better solution for users. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
