how to set class attributes for a host or group instead of a pool?
Sten Carlsen
stenc at s-carlsen.dk
Thu Nov 7 15:08:35 UTC 2013
On 07/11/13 15:14, Steve Rikli wrote:
> Interesting. If I follow your method, every host{} definition also has
> a corresponding subclass? Maybe I'm not understanding properly how
> subclasses are applied.
The subclass goes instead of the host.
>
>
>
> On Thu, Nov 07, 2013 at 02:57:52PM +0100, Sten Carlsen wrote:
>> You may want to consider using a construct with subclasses. I do that
>> for a slightly different purpose.
>>
>> I want to be able to switch each of my hosts between gateways, so I have
>> 3 classes, each with its own gateway and a long list of hosts connecting
>> each MAC to a specific class. Using this concept, I should think you
>> might use something like:
>>
>> class "pxe" {
>> match hardware;
>> next-server <tftp server>;
>> filename "pxelinux.0";
>> }
>>
>> class "norm" {
>> match hardware;
>> }
>>
>> subnet xx{
>> ...
>> }
>>
>> subclass "pxe2 1:00:01:02:03:04:05;
>> subclass "norm" 1:00:01:02:03:12:32;
>>
>>
>> I place the subclass declarations in a file that is included, all you
>> would have to do to change from pxe boot to normal boot is to change the
>> name of the subclass from "pxe" to "norm" and restart dhcpd.
>>
>>
>>
>> On 07/11/13 14:42, Steve Rikli wrote:
>>> Sure, we could just define the global class and let it apply to the
>>> known hosts/groups we already define, but without being able to
>>> selectively turn it off in the config (what I was hoping for with
>>> allow/deny functions) then we'd have to change the hosts' BIOS every
>>> time to enable/disable PXE. We're hoping to avoid that and instead
>>> control whether or not to PXE boot via DHCP.
>>>
>>> I was guessing we'd end up with something like your 2nd idea, which is
>>> workable. It's still a bit more repeating of multiple if-then etc.
>>> statements in each group than we would prefer, and we'll need to
>>> (un)comment those blocks of code (instead of 1 allow/deny line) to flip
>>> the on/off switch for PXE booting, but it's better than the alternative.
>>>
>>> Definitely worth trying in any case -- since we have no other solution
>>> at the moment. :-)
>>>
>>> Thanks,
>>> sr.
>>>
>>>
>>> the global class today and let it naturally apply
>>> On Thu, Nov 07, 2013 at 05:25:40PM +1100, Glenn Satchell wrote:
>>>> Your example below will work fine (as long as the syntax is ok). A
>>>> fixed-address host can still be a member of a class and obtain all the
>>>> class attributes.
>>>>
>>>> The allow/deny bit does not allow or deny the attributes of the class,
>>>> rather it allows or denies access to a pool based on membership of the
>>>> class.
>>>>
>>>> So, in your case *if* the host is booted as PXE it will have the
>>>> vendor-class-identifier set to PXEClient and so be a member of the
>>>> pxeclients class, and therefore have those class attributes (next-server,
>>>> etc) added to it. It gets its IP address in the same fixed-address way as
>>>> normal and everything should be fine.
>>>>
>>>> If it is booted normally, then it doesn't have the vendor-class-identifier
>>>> set to PXEClient and so it won't be a member of that class and won't have
>>>> those attributes (next-server, etc) set.
>>>>
>>>> If the above doesn't work for you, then put a group {} statement around
>>>> the host statements and add something like this in the group. You can make
>>>> the if statement as complex as you need to.
>>>>
>>>> group {
>>>> if substring(option vendor-class-identifier, 0, 9) = "PXEClient" {
>>>> next-server <tftp server>;
>>>> filename "pxelinux.0";
>>>> }
>>>> host ... { ... }
>>>> host ... { ... }
>>>> }
>>>>
>>>> regards,
>>>> -glenn
>>>>
>>>> On Thu, November 7, 2013 2:54 am, Steve Rikli wrote:
>>>>> Our DHCP is composed of groups of known hosts in multiple subnets,
>>>>> with fixed-address assignments based on hardware ethernet addresses.
>>>>>
>>>>> I'd like to use functionality similar to this typical example:
>>>>>
>>>>> class "pxeclients" {
>>>>> match if substring(option vendor-class-identifier, 0, 9) =
>>>>> "PXEClient";
>>>>> next-server <tftp server>;
>>>>> filename "pxelinux.0";
>>>>> }
>>>>>
>>>>> with allow/deny as needed; but it seems that global class can only be
>>>>> applied to pools with ranges, rather than a host or group of hosts.
>>>>>
>>>>> So today to enable pxebooting we usually add next-server & filename to a
>>>>> host{} (e.g. for a re-install situation) or to a group{} (e.g. when
>>>>> bringing up a new subnet or installing a new batch of clients, etc.).
>>>>> This works well enough, but gets cumbersome.
>>>>>
>>>>> Recently, we've added a new batch of hosts with UEFI as well as a legacy
>>>>> BIOS mode, so we're likely to need something more complex, e.g.:
>>>>>
>>>>> match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
>>>>> next-server <tftp server>;
>>>>> if option arch = 00:06 {
>>>>> filename "bootia32.efi";
>>>>> }
>>>>> else if option arch = 00:07 {
>>>>> filename "bootx64.efi";
>>>>> }
>>>>> else {
>>>>> filename "pxelinux.0";
>>>>> }
>>>>>
>>>>> which seems unwieldy to replicate in groups and individual hosts.
>>>>>
>>>>> Is there a more elegant way to define a global "class"-like function,
>>>>> potentially with multiple matches and if-then conditions, yet still be
>>>>> able to selectively enable/disable it for given groups and individual
>>>>> hosts, without replicating the whole block of code everywhere?
>>>>>
>>>>> Cheers,
>>>>> sr.
>>> _______________________________________________
>>> dhcp-users mailing list
>>> dhcp-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>>
>>
>> --
>> Best regards
>>
>> Sten Carlsen
>>
>> No improvements come from shouting:
>>
>> "MALE BOVINE MANURE!!!"
>> _______________________________________________
>> dhcp-users mailing list
>> dhcp-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
--
Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
More information about the dhcp-users
mailing list