how to set class attributes for a host or group instead of a pool?

Glenn Satchell glenn.satchell at uniq.com.au
Fri Nov 8 09:47:23 UTC 2013


With the sub-class you create an entry in one class or the other for each
mac address, eg:

subclass "pxe" 1:00:01:02:03:04:05;
subclass "pxe" 1:00:01:02:03:04:06;
subclass "pxe" 1:00:01:02:03:04:07;
subclass "pxe" 1:00:01:02:03:04:08;
subclass "norm" 1:00:01:02:03:12:32;

and

host ... { hardware ethernet 00:01:02:03:04:05; fixed-address ... }
host ... { hardware ethernet 00:01:02:03:04:06; fixed-address ... }
host ... { hardware ethernet 00:01:02:03:04:07; fixed-address ... }

If you have lots of hosts, then perhaps a script that generates the
included config files would be easier.

Note that with the subclass the mac address has a leading 1, this
represents the hardware type. 1 is for ethernet, and there are a couple of
others that are not used much these days.

regards,
-glenn

On Fri, November 8, 2013 3:19 am, Steve Rikli wrote:
> On Thu, Nov 07, 2013 at 04:39:18PM +0100, Sten Carlsen wrote:
>> On 07/11/13 16.28, Steve Rikli wrote:
>> > On Thu, Nov 07, 2013 at 04:08:35PM +0100, Sten Carlsen wrote:
>> >>
>> >> 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.
>> >
>> > Ah; so then how do you apply fixed-address and other host-specific
>> > parameters?
>>
>> In my use I don't, and it is not accepted in the subclass statement, so
>> maybe you need a host statement with the fixed-address and the
>> subclass/class for the other parameters?
>>
>> I have not tried, might be worth a try?
>
> Could be; I've tried a couple permutations so far without much success,
> and between your ideas and Glenn's, I've at least got some promising
> ideas again.
>
> Thanks,
> sr.
>
>
>> >>> 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?
>> >>>>>>>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>




More information about the dhcp-users mailing list