On 03/29/2011 01:37 PM, Michal Novotny wrote:
On 03/29/2011 01:16 PM, Paolo Bonzini wrote:
On 03/29/2011 12:52 PM, Michal Novotny wrote:
[snip]
It would be great to:
1) add<user-class> and<vendor-class> tags inside<dhcp> that allow
filtering according to user/vendor classes
Well, I didn't know this is supported by DNSMasq but it seems to be
Yes, I am using it. :)
Great. Good to implement this then however I'm not sure about the
<network-id> parameter for DNSMasq. What should network-id tag mean and
what should it match?
It can be a progressive number. You use it later to limit the "scope"
of --dhcp-boot options.
-4, --dhcp-mac=<network-id>,<MAC address>
Map from a MAC address to a network-id tag. The MAC
address may include wildcards. For example
--dhcp-mac=3com,01:34:23:*:*:* will set the tag "3com" for any host
whose MAC address matches the pattern.
Interesting.
Well, should we support this as well?
One step at a time...
3) add support for DHCP options besides bootp, with a tag like<option
force="yes|no" name="..." value="...">.
For example, my router's DHCP configuration would look like this:
<dhcp>
<range ...>
<user-class prefix="iPXE">
<bootp file="http://playground.usersys.redhat.com/pxe/boot.ipxe";>
</user-class>
<bootp file="undionly.kpxe">
</dhcp>
Basically this is using boot.ipxe file for the prefix of iPXE and
falling back to default undionly.kpxe... right? Is this what you mean by
your definition?
Yes.
second-term$ dig TXT "some name" @192.168.122.1 -p 52
;; ANSWER SECTION:
some\032name. 0 IN TXT "some value"
This is just how dnsmasq prints the request. You can see with wireshark
that the request is really for "some name". BTW, please test your patch
with commas in the name. Those should be forbidden probably (not sure
about the value).
You're right. It's really "some name" and it's matter of how dnsmasq
prints the request. Also, for the commas, I did try in both name and
value and it was not working at all in the name and for the value is was
showing 2 values basically:
;; ANSWER SECTION:
some\032name. 0 IN TXT "some" "value"
Value in wireshark is presented separated by a NULL byte, i.e.
"some\0value" (although wireshark shows comma character instead of \0
since it doesn't escape that way) so I guess we should disallow usage of
commas as well.
Perhaps no, it does have a meaning after all. I don't know much about
TXT records though.
To sum this up, we should disallow usage of commas and quotes (or we
should at least escape the quotes).
Commas only in the name, please. libvirt helpers should take care of
escaping quotes.
Paolo
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list