Re: [Dnsmasq-discuss] extension of configuration files
On Sun, Jul 5, 2009 at 4:29 PM, Carlos Carvalhocar...@fisica.ufpr.br wrote: Simon Kelley (si...@thekelleys.org.uk) wrote on 5 July 2009 16:41: I guess the problem is knowing _which_ files should be ignored ( how many conventions are there?) and not ignoring files which someone, somewhere, thinks are perfectly OK and should be used. That's clearly impossible. If you decide to do it there are only two possibilities: define the (only) extension in dnsmasq, or do it like apache, as Michael says. I think the later is too much bloat. I'd rather not have any exclusion but since you ruled this out we're left with the first alternative. What about just leaving it as it's now? :-) How about a compromise -- not a full wildcard syntax, but a user-controlled literal suffix match? e.g. conf-dir-suffix=.conf Or you could let other programs do the heavy lifting and have a just-in-time config command whose output is processed. Dangerous because it has to be run before forking as nobody, but very powerful: jit-config=/bin/sh -c cat /etc/conf.d/dnsmasq/*.conf ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] extension of configuration files
On Sun, Jul 5, 2009 at 5:20 PM, richardvo...@gmail.comrichardvo...@gmail.com wrote: How about a compromise -- not a full wildcard syntax, but a user-controlled literal suffix match? e.g. conf-dir-suffix=.conf Or you could let other programs do the heavy lifting and have a just-in-time config command whose output is processed. Dangerous because it has to be run before forking as nobody, but very powerful: jit-config=/bin/sh -c cat /etc/conf.d/dnsmasq/*.conf Just a couple of thoughts and I'll let Simon finish digesting this thread. I have an objection to the apache multiple includes approach. I think that the only way to make room for this is to rip out the current behavior of accommodating for the various emacs patterns Simon mentioned earlier in the thread to make room for this. I question the need for the apache include approach since apache will let you specify more than one include statement. Dnsmasq has few enough options that a single directory with multiple files is really sufficient. the conf-dir-suffix idea really seems to be the most flexible, and the easiest to add in the current mix.
Re: [Dnsmasq-discuss] ethers should have precedence over client dhcp request
Am 05.07.2009 21:45, schrieb Simon Kelley: Felix Schwarz wrote: I have the situation that I changed the ip address in /etc/ethers. However when the client sends a DHCPREQUEST with its old address (because the lease is still valid) dnsmasq sends a DHCPACK and renews the lease. Therefore the client could use the ip indefinitely. Is that correct or did I misinterpreted my logs? What I would like to see is that /etc/ethers has precedence over the lease file. If a new DHCPDISCOVER / DHCPREQUEST comes in, dnsmasq should check the ethers and offer only the ip address which is written there. That's the designed behavior: dnsmasq should send a DHCPNAK when a client has a defined IP address and the client renews a lease for a different address. The DHCPNAK will force the client to go through the whole DISCOVER/REQUEST cycle. I suspect that your problems with duplicate IP addresses in /etc/ethers may have confused this, but if you have a clear case where it's not working, please let me have details and I'll check it out as a possble bug. Cheers, Simon. Hi Simon, i have the same probleme here. I just plugged in the network-cable to my VoIP-Phone (snom 360). Snom discovered for an ip-address and dnsmasq gave it a free address in the dhcp-pool. After that, i added the mac-address to the dhcp-host-addresses and set the ip-address to a different one. Snom 360 allways got DHCPACK for requesting the old ip-address. I had to delete the dhcp-lease-file-entry and restart dnsmasq. Michael.
Re: [Dnsmasq-discuss] extension of configuration files
Helmut Hullen wrote: Hallo, Carlos, Du meintest am 05.07.09: I guess the problem is knowing _which_ files should be ignored ( how many conventions are there?) and not ignoring files which someone, somewhere, thinks are perfectly OK and should be used. That's clearly impossible. If you decide to do it there are only two possibilities: define the (only) extension in dnsmasq, or do it like apache, as Michael says. I think the later is too much bloat. I'd rather not have any exclusion but since you ruled this out we're left with the first alternative. If dnsmasq had defined allowed extensions from the beginning there would be no problem, but it hasn't. And therefore every user may have declared his own extensions (or no one). Therefor dnsmasq cannot change its behaviour - I had forgotten this small problem ... What about just leaving it as it's now? :-) Under my slackware installation I'll write my special slackware extension watcher ... it first has to look what's the name of conf- dir. Ugly. There's an alternative which is backwards compatible: extend the --conf-dir option optionally allow extensions which should _NOT_ be used, so the correct form to solve the initial problem would be --conf-dir=/etc/dnsmasq.d,.new I guess that for completeness, more than one extension should be allowed. That would meant that (for instance) the Debian dnsmasq package, which automatically reads /etc/dnsmasq.d for config fragments dropped by other packages, could ignore *.dpkg-dist *.dpkg-old and *.dpkg-new. That's a useful improvement. Cheers, Simon.
Re: [Dnsmasq-discuss] extension of configuration files
Hallo, Simon, Du meintest am 06.07.09: Under my slackware installation I'll write my special slackware extension watcher ... it first has to look what's the name of conf- dir. Ugly. There's an alternative which is backwards compatible: extend the --conf-dir option optionally allow extensions which should _NOT_ be used, so the correct form to solve the initial problem would be --conf-dir=/etc/dnsmasq.d,.new I guess that for completeness, more than one extension should be allowed. Sounds very good - thank you! Viele Gruesse! Helmut
Re: [Dnsmasq-discuss] extension of configuration files
On Mon, Jul 6, 2009 at 1:17 AM, Helmut Hullenhul...@t-online.de wrote: Hallo, richardvo...@gmail.com, Du meintest am 05.07.09: What about just leaving it as it's now? :-) How about a compromise -- not a full wildcard syntax, but a user-controlled literal suffix match? e.g. conf-dir-suffix=.conf And then many old installations which have files with no extensions get problems ... Perhaps something like either no extension or extension = .conf may solve the most problems. Or you could let other programs do the heavy lifting and have a just-in-time config command whose output is processed. Dangerous because it has to be run before forking as nobody, but very powerful: jit-config=/bin/sh -c cat /etc/conf.d/dnsmasq/*.conf My distribution (slackware) has no /etc/conf.d directory - that's the second problem. Each user (sysadm) can define his (or her) own conf- dir. Viele Gruesse! Helmut I guess I didn't explain these were meant to be examples of configuration options, that the user could edit to suit themselves, just like every other configuration option dnsmasq provides. If slackware doesn't have /etc/conf.d then supply your own command for finding the configuration. And the default would be no external configuration directory, just like it is today. But Simon's solution of a user-defined list of suffixes to exclude seems an ideal tradeoff between flexibility and complexity.
Re: [Dnsmasq-discuss] ethers should have precedence over client dhcp request
On Mon, Jul 6, 2009 at 2:46 AM, Michael Rackdnsmasq.l...@michaelrack.de wrote: Am 05.07.2009 21:45, schrieb Simon Kelley: Felix Schwarz wrote: I have the situation that I changed the ip address in /etc/ethers. However when the client sends a DHCPREQUEST with its old address (because the lease is still valid) dnsmasq sends a DHCPACK and renews the lease. Therefore the client could use the ip indefinitely. Is that correct or did I misinterpreted my logs? What I would like to see is that /etc/ethers has precedence over the lease file. If a new DHCPDISCOVER / DHCPREQUEST comes in, dnsmasq should check the ethers and offer only the ip address which is written there. That's the designed behavior: dnsmasq should send a DHCPNAK when a client has a defined IP address and the client renews a lease for a different address. The DHCPNAK will force the client to go through the whole DISCOVER/REQUEST cycle. I suspect that your problems with duplicate IP addresses in /etc/ethers may have confused this, but if you have a clear case where it's not working, please let me have details and I'll check it out as a possble bug. Cheers, Simon. Hi Simon, i have the same probleme here. I just plugged in the network-cable to my VoIP-Phone (snom 360). Snom discovered for an ip-address and dnsmasq gave it a free address in the dhcp-pool. After that, i added the mac-address to the dhcp-host-addresses and set the ip-address to a different one. Snom 360 allways got DHCPACK for requesting the old ip-address. I had to delete the dhcp-lease-file-entry and restart dnsmasq. I don't think you had to delete the lease entry, you definitely needed to restart dnsmasq because the configuration is cached at startup. There's a signal for re-reading some files but not the main configuration. Michael. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] ethers should have precedence over client dhcp request
Hi Richard, i am an advanced user :-D You don't have to tell me, that i have to restart dnsmasq in order to reload the configuration-data ;-) Of course, dnsmasq was restarted after changing the configuration, but no ip-change on the client was affected. Michael. Hi Simon, i have the same probleme here. I just plugged in the network-cable to my VoIP-Phone (snom 360). Snom discovered for an ip-address and dnsmasq gave it a free address in the dhcp-pool. After that, i added the mac-address to the dhcp-host-addresses and set the ip-address to a different one. Snom 360 allways got DHCPACK for requesting the old ip-address. I had to delete the dhcp-lease-file-entry and restart dnsmasq. I don't think you had to delete the lease entry, you definitely needed to restart dnsmasq because the configuration is cached at startup. There's a signal for re-reading some files but not the main configuration.
Re: [Dnsmasq-discuss] extension of configuration files
Helmut Hullen wrote: Hallo, Simon, Du meintest am 06.07.09: Under my slackware installation I'll write my special slackware extension watcher ... it first has to look what's the name of conf- dir. Ugly. There's an alternative which is backwards compatible: extend the --conf-dir option optionally allow extensions which should _NOT_ be used, so the correct form to solve the initial problem would be --conf-dir=/etc/dnsmasq.d,.new I guess that for completeness, more than one extension should be allowed. Sounds very good - thank you! Try this: http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.50test6.tar.gz which implements it (many extensions). Cheers, Simon.
Re: [Dnsmasq-discuss] extension of configuration files
Hallo, Simon, Du meintest am 06.07.09: --conf-dir=/etc/dnsmasq.d,.new I guess that for completeness, more than one extension should be allowed. http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.50test6.tar.gz which implements it (many extensions). Works like a charm - thank you! One more problem solved. Viele Gruesse! Helmut
Re: [Dnsmasq-discuss] Best way to assign different static IPs on different VLANs?
Hi Richard... On 7/4/09 6:47 PM, richardvo...@gmail.com wrote: dnsmasq will only consider address matches from the same subnet as the local IP address(es) on the interface where the request arrived. But you may have to use dnsmasq configuration (dhcp-host) instead of /etc/ethers, because as you say /etc/ethers doesn't provide space for multiple IPs. dhcp-host can match based on MAC address instead of client id. Thanks for the suggestion. This is actually the first thing I tried, but it didn't work. I think the reason is that the later dhcp_host line overrides the earlier one when they both have the same MAC address listed. What you suggest would have worked fine (with no special configuration) if I was willing to accept a dynamic IP, but it won't work for static IPs. It worked with client IDs because I was able to make the names different, preventing the rules from clashing with one another. After doing some more reading, I think the option I need is the dhcp-fqdn option in dnsmasq 2.46, possibly combined with the support there for the ability to associate domains with specific subnets. Unfortunately, I'm currently running an older release of dnsmasq (2.35) on my Linksys router, so I've been unable to try this yet. If I'm reading things right, though, this would let me put the unqualified name in /etc/ethers and have qualified names in two different domains in /etc/hosts and have dnsmasq assign the right IP depending on which domain was associated with the subnet the request arrived on. Can anyone confirm this for me? Is there any way to get this kind of behavior with pre-2.46 dnsmasq? It looked to me at one point like localise-queries might have been enough here, but that didn't seem to be enough. On Sat, Jul 4, 2009 at 7:14 PM, Ron Frederickr...@timeheart.net wrote: Hello... I have been using dnsmasq for a number of years now and it has been working great. I recently rearranged my network slightly, though, and while I have the new configuration working again, I'm wondering if there's a better way to do what I'm trying to do. Basically, I have two subnets at home. One of them is a public /29 subnet provided by my ISP. The other is a local 192.168.1.0/24 network I use for internal hosts. I have dnsmasq running on a Linksys WRT54GS under OpenWRT. One of my hosts needs to be on both networks, so am I using VLANs on both the Linksys and the host for this. VLAN 1 on the Linksys is my public subnet and VLAN 2 is my private one. On both the Linksys and the dual-homed host, I use VLAN tagging to keep the private network traffic separate from the public traffic. What I'd like to do is have dnsmasq automatically assign a static public IP when it sees a request on VLAN 1 and a static private IP when it sees a request on VLAN 2, even though it will see the same MAC address in both requests. Can this be done? Normally, I just fill in MAC address information in /etc/ethers and host information in /etc/hosts and the static mapping is automatically made. However, since I can only associate a single name with the MAC address in /etc/ethers, I'm not sure how to configure the two different IPs I'd like to assign. For now, I have told the dual-homed host to use different client IDs (foo and foo-private) in its two requests, and then added entries like: dhcp-host=id:foo,foo dhcp-host=id:foo-private,foo-private By putting entries in /etc/hosts for foo and foo-private, the right thing seems to happen. However, it feels like there should be a way to do this without using client IDs, since dnsmasq knows which VLAN the request is arriving on. I've checked through the documentation and I don't see anything which covers this specific case. Is there a way to do what I'm looking to do? -- Ron Frederick r...@timeheart.net
