On Tue, Jul 24, 2018 at 5:11 AM, Henrik Lindberg <[email protected]
> wrote:
> On 2018-07-24 03:17, Nick Hasser wrote:
>
>> I am required to configure FreeRADIUS with a white list of authorized
>> MACs that are allowed on my network. I currently have a module that uses a
>> file resource to drop the authorized_macs file selected by hostname of the
>> server from my modules file directory. For example, currently server1 gets
>> freeradius/files/server1_authorized_macs dropped into the proper
>> location.
>>
>> I am also using ghoneycutt/hosts to manage /etc/hosts on my servers.
>> Every devices that is required to be listed in the authorized MACs file has
>> an /etc/hosts entry managed via this module and defined in the server's
>> yaml file.
>>
>> I would like to modify my freeradius module to dynamically build the
>> authorized_macs file based based on data in hiera instead of managing a
>> file per server in my module. I plan to add a key to the existing
>> hosts::host_entries hash already in place for the ghoneycutt/hosts module
>> that contains the MAC of the host and use that to generate my
>> authorized_macs file.
>>
>> Is the sample code below on the right path for this? This is the first
>> time I've done anything more complicated than a simple variable lookup in
>> hiera. I haven't tested any of the code below, just trying to get an idea
>> if I'm heading down the right path first.
>>
>> sample hiera node file:
>> hosts::host_entries::
>>
>
> You have an extra ':' at the end. Drop that.
>
> 'fqdn-1':
>> ip: '192.168.1.1'
>> host_aliases:
>> - 'host-1'
>> mac: '00-00-00-00-00-11'
>> 'fqdn-2':
>> ip: '192.168.1.2'
>> host_aliases:
>> - 'host-2'
>> mac: '00-00-00-00-00-22'
>>
>> freeradius/manifests/config.pp
>> class config (
>> $host_entries = $hosts::host_entries
>>
>
> Use Hash $host_entries = ...
> as that will give you automatic type checking - see below:
>
> ) {
>> validate_hash($host_entries)
>>
>
> With added type checking in the signature, you can skip this (deprecated)
> call to validate_hash()
>
> $host_entries.each |$host_entry| {
>>
>
> This will result in each entry in the hash to be given to the lambda
> as a Tuple of [key, value]; not a hash. You want:
>
> $host_entries.each | $hostname, $values | {
>
> validate_hash($host_entry)
>>
>
> You can get rid of this validation as well. In your example it would also
> fail because the entries will not be hashes. See above.
>
> If you type your class parameter, you can make it more specific:
>
> class config ( Hash[String, Hash] $host_entries = $hosts::host_entries)
>
> Now you know that it is a hash of string keyed hashes, and there is no
> need to check again. You can also be even more detailed with a Struct
> data type where you can specify exactly which keys you expect in the hash,
> if they are required or not:
>
> class(
> Hash[String,
> Struct[{
> Optional['ip'] => String, # or a Pattern datatype for IP
> Optional['host_aliases'] => Array[String]
> Optional['mac'] => String, # or a Pattern datatype for MAC
> }]
> ] $host_entries = ...
> )
>
> If you want to you can give the struct type a name and make it autoloaded.
> You can do the same with the Hash if you like.
>
> type HostDetals = Hash[String,
> Struct[{
> Optional['ip'] => String, # or a Pattern datatype for IP
> Optional['host_aliases'] => Array[String]
> Optional['mac'] => String, # or a Pattern datatype for MAC
> }]
>
> And then write:
>
> class( HostDetails $host_entries = ... )
>
> $host_entry.each | $title, $attributes| {
>>
>
> The $title will be 'ip', 'mac', 'host_alias', and the $attributes
> will be either a string or an Array (at least in your example data)
>
> validate_hash($attributes)
>>
>
> ... so this is clearly wrong.
> And if you take the advice to use a data type, you don't need to check
> again here.
>
> if has_key($attributes, 'mac') {
>>
> This is not right.
> Simply do:
>
> case $title {
> 'ip' : {
> # code for ip
> }
> 'max' : {
> # code for mac
> }
> 'host_aliases': {
> # code for host_aliases
> }
> }
>
> #insert code here to add the $mac to the authorized_macs file on
>> this server
>> }
>> }
>> }
>> }
>>
>>
>>
> Hope the comments above will help you.
>
Thanks for the comments and examples. It is making more sense now. I'll
keep digging into the documentation to make sure I understand custom types
and structs better.
Nick
>
> Best,
> - henrik
>
> Thanks,
>> Nick Hasser
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <mailto:
>> [email protected]>.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/puppet-users/CAAmyyqoCr-Ni9%3DtKeFYH65vhPxoxKx6xJxO8PBbS
>> 0Xaa%2BfCPzw%40mail.gmail.com <https://groups.google.com/d/m
>> sgid/puppet-users/CAAmyyqoCr-Ni9%3DtKeFYH65vhPxoxKx6xJxO8PBb
>> S0Xaa%2BfCPzw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
>
> Visit my Blog "Puppet on the Edge"
> http://puppet-on-the-edge.blogspot.se/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/puppet-users/pj6qbd%24fmp%241%40blaine.gmane.org.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAAmyyqpWeqxyu4rGqp0HykuXJa%3DNw8%3DPzN1T%3DdrMFVtrVtke-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
