djjudas21 / puppet-freeradius Goto Github PK

The config of logrotate does not take into account that the pid file is in /var/run/freeradius/freeradius.pid on Debian
postrotate => 'kill -HUP cat /var/run/radiusd/radiusd.pid'

Also, does the UID need to be set numerically? Won't the package set it if it's required?

(I probably should have checked with you before raising a million tickets ;) )

Pull request #123 addresses this issue by removing the restriction of the users parameter being an Array of Hashes within the files module.

Please add support for Puppet 6.
We are deprecating our (example42) freeradius module and will mention this module as replacement.

If this is not the correct forum for a question like this I apologize. Just attempting to figure out what I am doing incorrectly. Thank you for you time.

When using the following code:

#Configure file module here for mac authorization
  freeradius::module::files {'authorized_macs':
    source => 'puppet:///modules/pinn_radius/authorized_macs',
    key       => '%{Calling-Station-ID}',
  }

I receive and error Error:

Validation of File[/etc/raddb/mods-config/authorized_macs/authorize] failed: You cannot specify more than one of content, source, target at /etc/puppetlabs/code/environments/production/modules/freeradius/manifests/module/files.pp:52

When I use this instead no error occurs

#Configure file module here for mac authorization
  freeradius::module::files {'authorized_macs':
    key       => '%{Calling-Station-ID}',
    content => '[00:00:00:AA:FF:BB]',
  }

Do you have any thoughts on what I am doing incorrectly?

Tue Nov 24 10:47:54 2015 : Warning: 'netmask' field found in client testswitch is deprecated, use CIDR notation instead. Please fix your configuration
Tue Nov 24 10:47:54 2015 : Warning: Support for 'netmask' will be removed in a future release

Proposing we use "main" as the primary branch, rather than "master". While I absolutely agree with the cultural reasons for this, I'm proposing this more because this is going with the flow of the industry.

PDK was updated to expect the git main branch to be "main". This is configurable, but having custom config in there for each instance this comes up feels like we'll be paddling against the flow.

I don't think this would a significant change - we would update any PRs in flight (and all but one are mine so fine by me!).

The permissions for a couple of directories are too tight, I think/etc/raddb and /var/log/freeradus can be relaxed to 0755, as it circumvents using tab completion for the config files when working with sudo on systems.

When i try to use the ressources home_server_pool via a very simple configuration :

  freeradius::home_server { "localhost":
    secret => 'xxxx',
    ipaddr => '127.0.0.1',
  }

  freeradius::home_server_pool { "my_auth_failover":
    home_server => 'localhost',
  }

I got a error :

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Function Call, Failed to parse template freeradius/home_server_pool.erb:
  Filepath: /etc/puppet/code/environments/radius/modules/freeradius/templates/home_server_pool.erb
  Line: 6
  Detail: undefined method `each' for "localhost":String
 at /etc/puppet/code/environments/radius/modules/freeradius/manifests/home_server_pool.pp:18:16

I'm not a puppet expert but it's look like, the file templates/home_server_pool.erb need a small change to work as expected :

diff templates/home_server_pool.erb templates/home_server_pool.erb.old 
6,7c6,7
< <% if defined?(@home_server) -%>
< 	home_server = <%= @home_server %>
---
> <% @home_server.each do |server| -%>
> 	home_server = <%= server %>

Due to the validate_re failing the module, on Debian/Jessie I'm unable to bootstrap a working Freeradius from 1labs repo. Can this be replaced with a warning instead?

 apt::source { '1labs':
    comment  => "1Labs Freeradius ${release} repository",
    location => 'http://pkg.1labs.ch/debian',
    release  => "${release}-1labs",
    repos    => 'fr30-release',
    key      => {
      id     => '13C0A89B5C671AAB72DC07B47DADAF130A2FCD77',
    },
  } ->

  class { '::freeradius':
    preserve_mods => false,
    utils_support => true,
  }

The manifests currently reference files by their full name, which makes creating specs difficult. Instead, the name should be generic, and have a path attribute, for example:

file { "${fr_moduleconfigpath}/attr_filter/${name}":

should be:

file { "freeradius attr_filter ${name}":
   path => "${fr_moduleconfigpath}/attr_filter/${name}",

Similarly, systemd units, etc. which differ per-OS should use a common name regardless of OS.

Currently, all the specs assume redhat, so only redhat is fully tested.

(I am currently working on this and testing in my environment, PR to come this week)

3.2 is out - not in major distros yet AFAIK, but... at least I'm using it with home cut packages.

This will mean some config changes. Logic within the templates checking version numbers will be very messy and hard to update for new versions, I think - I am thinking in order to make this work we might need sets of config templates per version. Freeradius 4.0 will have similar needs.

We have had some changes in early 3.0.x to later 3.0.x which required template updates as well - which could have been perhaps better done as separate templates rather than updating in place.

I'm not too sure - I don't think we want to end up with a template tree for every version, but, backwards incompatible changes perhaps?

Perhaps a function to resolve template filenames - so we only create new ones if required, rather than lots of duplicates.
Gets a bit messy though, if we have a bugfix to one, we may have to update 3 or 4...

There is an undocumented boolean configuration option in the tls configuration of FreeRADIUS named allow_expired_crl. It's very helpful in the case that a CRL expires before it is replaced and FreeRADIUS is restarted. You can see it in the source code here: https://github.com/FreeRADIUS/freeradius-server/search?utf8=%E2%9C%93&q=allow_expired_crl&type=

Can you add support for allow_expired_crl in freeradius::module::eap?

Per https://github.com/djjudas21/puppet-freeradius/blob/3.5.0/templates/eap.erb#L126-L159 , a closing curly bracket can be left dangling is $eap_gtc is true (default) and $gtc_challenge is undef (default).

Here is the output I see when using nothing but the defaults... egrep -v '\s*#' /etc/raddb/mods-enabled/eap | grep -v '^$' (lines 11-12 are questionable):

eap {
  default_eap_type = md5
  timer_expire     = 60
  ignore_unknown_eap_types = no
  cisco_accounting_username_bug = no
  max_sessions = ${max_requests}
  md5 {
  }
  leap {
  }
    auth_type = PAP
  }
  tls-config tls-common {
    private_key_file = ${certdir}/server.pem
    certificate_file = ${certdir}/server.pem
    ca_file = ${certdir}/ca.pem
    dh_file = ${certdir}/dh
    ca_path = ${cadir}
    cipher_list = "DEFAULT"
    ecdh_curve = "prime256v1"
    cache {
      enable = yes
      max_entries = 255
    }
    verify {
    }
    ocsp {
      enable = no
      override_cert_url = yes
      url = "http://127.0.0.1/ocsp/"
    }
  }
  tls {
    tls = tls-common
  }
  ttls {
    tls = tls-common
    default_eap_type = md5
    copy_request_to_tunnel = no
    use_tunneled_reply = no
    virtual_server = "inner-tunnel"
  }
  peap {
    tls = tls-common
    default_eap_type = mschapv2
    copy_request_to_tunnel = no
    use_tunneled_reply = no
    virtual_server = "inner-tunnel"
}
  mschapv2 {
  }
}

I suspect you want to move the gtc { clause to above https://github.com/djjudas21/puppet-freeradius/blob/3.5.0/templates/eap.erb#L138 , but will leave that for you to decide.

Error I am seeing from radiusd -X:

/etc/raddb/mods-enabled/eap[604]: Too many closing braces
Errors reading or parsing /etc/raddb/radiusd.conf

Cheers.

hi,

I just want to ask, of there is any plan for Hiera support. I tried to configure for example the LDAP module, like

freeradius::module::ldap: 'ensure'
freeradius::module::ldap::identity: 'cn=webadmin,ou=Accounts,dc=example,dc=com'
freeradius::module::ldap::password: 'secret'
freeradius::module::ldap::basedn: 'ou=People,dc=example,dc=com'

but it seems not working. So either I calling the class wrong, or it won't work with Hiera, so I have to create a profile class.

Any suggestions ?

The eap module uses a parameter named tls_verify_client but the eap template uses tls_client. Pull request #123 corrects this by renaming the use of tls_client in the eap template to tls_verify_client.

shortname param in freeradius::client should be optional, and if left undefined it should take the resource title

Restucturing the module could make the code cleaner and easier to read. Example branch below, would you be interested to incorporate such changes (without losing backwards compatibility?), although might remove support for puppet 3.x.

• https://github.com/sts/puppet-freeradius/tree/new/data/os
• `https://github.com/sts/puppet-freeradius/tree/new/manifests

https://github.com/djjudas21/puppet-freeradius/blob/master/manifests/client.pp#L19 requires an integer, but I would like to use the string '1812-1813 or array [1812,1813], which is valid for passing along to the firewall resource. Can you consider using Variant[Array[Integer],Integer]?

This issue was split out from #149 (comment)

It turns out if you have a fact which calls Facter.value for something, it runs whatever commands it needs, rather than using whatever comes from rspec-puppet-facts.

I think there are probably more modern ways to handle this - using confine or similar - but that's thing for another day.

on the documentation, it's missing the ressources freeradius::listen

I'm proposing something like this in the README :

#### `freeradius::listen`

Define listening interface 

##### `type`
Default: `auth`. 
Must be one of : Enum['auth','acct','proxy','detail','status','coa']

##### `ip`
Default: `undef`. The IPv4 address of the interface to listen. `ip` and `ip6` are mutually exclusive.

##### `port`
Default: `undef`.

##### `max_connections`
Default : 16

##### `lifetime`
Default : 0

##### `idle_timeout`
Default : 30

I have been using puppet for about 6 months and figured radius is a good candidate to "puppetize". I am running Ubuntu 15.10 which I know is not officially supported but it should be possible to fix things so that it will work. I have not written any modules so am limited in my knowledge in that area.

I have FreeRADIUS 3.0.11 installed on a client but when running the agent I get a message saying that it is only compatible with FreeRADIUS 3. I have changed that error to a warning, but then get into all kinds of missing things for logrotate. Any suggestions where to start?

$ freeradius -v
radiusd: FreeRADIUS Version 3.0.11, for host x86_64-pc-linux-gnu, built on Mar 25 2016 at 19:13:16
Copyright (C) 1999-2016 The FreeRADIUS server project and contributors
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE
You may redistribute copies of FreeRADIUS under the terms of the
GNU General Public License
For more information about these matters, see the file named COPYRIGHT
$ sudo /opt/puppetlabs/bin/puppet agent -t
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Evaluation Error: Error while evaluating a Function Call, This module is only compatible with FreeRADIUS 3 at /etc/puppetlabs/code/environments/production/modules/freeradius/manifests/init.pp:17:5 on node sdga.vsdb.ca
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
$

Like with the samba module before, I can't readily identify an appropriate syslog module to include.

Dist: Debian/Buster
Package: freeradius
Version: 3.0.17+dfsg-1.1

Logrotate fails with the following error, since the package distributed logrotate config and the puppet module config have duplicate definitions for radius log files:

logrotate[27780]: error: freeradius:18 duplicate log entry for /var/log/freeradius/checkrad.log
logrotate[27780]: error: found error in file freeradius, skipping
logrotate[27780]: error: radiusd:4 duplicate log entry for /var/log/freeradius/radius.log
logrotate[27780]: error: found error in file radiusd, skipping
systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE

Latest on puppet forge is 3.8.1 which doesn't support Debian 10

Thanks!

The puppet language style guide (https://puppet.com/docs/puppet/7.6/style_guide.html) recommends using data binding rather than the params.pp pattern.

As well as being a more "modern" way of doing things, this also allows the user to override anything that params.pp would currently be calculating - making the module a lot more flexible.

This has the negative impact that the module's supported minimum Puppet version would be 4.9, as this is when Hiera 5 with in-module hiera data support was added. Given this was released in 2017 I think this is an OK minimum version.

The current minimum version is 4.0.0 (2015).

An example of this would be:
hiera.yaml:

---
version: 5

defaults:
  datadir: data
  data_hash: yaml_data

hierarchy:
  - name: "osfamily+osname/major release"
    paths:
      - "os/%{facts.os.name}/%{facts.os.release.major}.yaml"
      - "os/%{facts.os.family}/%{facts.os.release.major}.yaml"
  - name: "osfamily+osname"
    paths:
      - "os/%{facts.os.name}.yaml"
      - "os/%{facts.os.family}.yaml"
  - name: 'common'
    path: 'common.yaml'

data/debian/9.yaml:

---
freeradius::package: freeradius
freeradius::raddbdir: '${sysconfdir}/freeradius/3.0'
#... etc ...

It would also mean making most (if not all) of the fr_* variables be straight params on the freeradius class, i.e., for the above examples:

class freeradius (
  String $package,
  String $raddbdir,
#  .. etc ..
) {
# .. code ..
}

This project has been a bit unloved since I switched jobs in 2018 and stopped using this FreeRADIUS Puppet module in production. Since then I've been happy to accept pull requests and release new versions, but it's becoming clear that the module could do with a new maintainer - someone who actually uses the module.

I have started conversations with Vox Pupuli, the Puppet community group who maintain third-party modules about taking ownership but I also wanted to shout out to everyone who has forked or contributed to this code already in case anyone wants to help with maintenance:

@amateo @steadramon @sts @deligatedgeek @diranged @nward @coreone @rogermartensson @JonTheNiceGuy @OlivierLM @guest715 @ardrigh @mrobbert @geoffdavis @davidc @infracaninophile @carlgarner @starryparrot @craigwatson @treydock @pioto @rotanid @theosotr @ihpu @raphink @davidc0le @paulseward @bhechinger @BrandwatchLtd @broadinstitute @ceesco53 @chihoko @chris-gibbs @claranet @ConclusionMC @cwmoller @dabelenda @decibelhertz @djfraggle @eniuz @gwdg @hihiuztrewq @janit42 @krobertson @Lavaburn @mlosapio @pikseluls @riseops @ross-w @roumano @SearchLightNZ @sklemer1 @sohonet @SuPair @zennoc @zivis

Sorry for the mass tagging... feel free to unwatch this issue if you're not interested. Thanks! 😄

Hi,

After a FreeRADIUS upgrade on RHEL 8 (freeradius-3.0.20-3.module+el8.3.0+7597+67902674.x86_64), FreeRADIUS stopped working with this error in the logs:

Systemd start for radiusd failed!
journalctl log for radiusd:
-- Logs begin at Tue 2020-12-29 04:36:26 CET, end at Tue 2021-01-12 18:22:30 CET. --
Jan 12 18:22:30 <redacted> systemd[1]: Starting FreeRADIUS high performance RADIUS server....
Jan 12 18:22:30 <redacted> sh[1960192]: /bin/sh: /etc/raddb/certs/bootstrap: No such file or directory
Jan 12 18:22:30 <redacted> systemd[1]: radiusd.service: Control process exited, code=exited status=127
Jan 12 18:22:30 <redacted> systemd[1]: radiusd.service: Failed with result 'exit-code'.
Jan 12 18:22:30 <redacted> systemd[1]: Failed to start FreeRADIUS high performance RADIUS server..

I guess this is due to

What would be the best solution, keeping this file, or dropping a systemd override to prevent the service from calling this script as part of its ExecStartPre command?

Firstly, great module! It would be nice to be able to manage sql.conf if mysql support is enabled (requires at least the sql credentials). How do you see managing these as well as sql/mysql/schema.sql and sql/mysql/dialup.conf?

Hello,

I'm trying to deploy certs.

freeradius::cert { 'RootCA01-2019.crt':
    content => '-----BEGIN CERTIFICATE-----MIIFETCCAvmgAwI......',
    type    => 'cert',
    }

Nothing is created in certs directory.

But if I create a dumb file, the module is OK :
Info: /Stage[main]/Freeradius/File[/etc/raddb/certs/toto.crt]: Filebucketed /etc/raddb/certs/toto.crt

Could you please help me ?

Thank you

Affects:

/manifests/init.pp

file['/var/log/radius', '/var/log/radius/radacct'], file['/var/log/radius/radius.log']

/templates/radiusd.conf.erb

logdir = ${localstatedir}/log/radius

/files/radiusd.logrotate (many locations) - perhaps needs to be changed to a template?

When I configure a LDAP server using create_resource from hiera:

freeradius::module::ldap:
  'name_of_ldap':
    server: '192.168.0.1'
    ....

Then an entry gets created in the folder mods-enabled named 'name_of_ldap' with this content:

ldap name_of_ldap {
  server = '192.168.0.1
  ....
}

Which seems correct, but the FreeRadius server won't start and this error appears in the log:

Error: /etc/raddb/sites-enabled/name_of_ldap[75]: Unknown attribute 'LDAP-Group'

BUT when I remove name_of_ldap from the mod, so then it looks like this:

ldap {
  server = '192.168.0.1
  ....
}

It works fine. Am I missing something? Or is the code not correct.

I'm proposing a new release major version 4 - to signal that there are some breaking changes (which I think there are).

I'd like to create a milestone for it, and tag a couple of issues (and maybe create some issues) which can be part of that milestone, then we have a goal to work towards.

I think we can leave this issue open as a way to track any general discussion on v4 (if that's what we agree it should be called, if not we can rename this to something else).

Hello, thanks for creating this module!

I got a little confused by the following error.

Evaluation Error: Error while evaluating a Function Call, Logrotate::Rule[wtmp]: rotate must be an integer at /etc/puppetlabs/code/environments/production/modules/logrotate/manifests/rule.pp:306:7 at /etc/puppetlabs/code/environments/production/modules/logrotate/manifests/defaults/debian.pp:16

I noted from the puppet forge dependencies page that your module had a dependency on rodjek/logrotate. I added it manually in my Puppet file.

After some head scratching I looked at your metadata.json file and realized it was actually yo61/logrotate (which has now been migrated to puppet/logrotate). Switching to that package fixed the error.

I wanted to let you know incase others might go down the same hole.

Thanks again!

The syntax of ldap configuration have been change in freeradius , i got this warning when i start the daemin in debug mode :

Listing multiple LDAP servers in the 'server' configuration item is deprecated and will be removed in a future release.  Use multiple 'server' configuration items instead
- server = 'ldap1,ldap2'
+ server = 'ldap1'
+ server = 'ldap2'

Can you update the resource freeradius::module::ldap to follow this ?

I can't find which samba module I should be looking for...

I have recently moved to the main branch of the puppet-freeradius module and freeradius failed to start after puppet ran. The issue was created by this commit d857d62, when the detail.erb template was updated to be the same as the detail example file in freeradius, which doesn't work because freeradius requires each module to be named and detail doesn't contain one. The detail.log example file does contain a name.

I can create a PR for this

Debian stretch was released in June now installs freeradius (3.0.12+dfsg-5+deb9u1) as standard so will you be updating package this to support Debian 9?

https://packages.debian.org/stretch/arm64/freeradius

Thanks?

Currently this module has a dependency on an old version of Puppetlabs/firewall, are there any plans to update this dependency?

I am happy submit a PR for a newer version

Home-written puppet defined types such as radius::client lack an "ensure" method that can be used to remove them.

When setting firewall to true for a client resource, the rule is repeatedly added to the iptables INPUT chain for each Puppet run. The problem appears to be with lines 61 and 68 in client.pp. The hyphen that follows the 100 i.e. 100**-**${shortname} needs to be replaced with a space in order for the Firewall resource to be able to match the rule on subsequent Puppet runs after it has been added to the iptables INPUT chain.

They are not needed anymore and it even gives a warning if you have them.

@jgazeleyfr in #129 (comment)_ you mentioned that you are not able to continue working on this module.
Do you see the possibility to migrate the module to voxpupuli so we can collaboratively continue working on this module?

https://voxpupuli.org/docs/migrate_module/

In the file /manifests/init.pp are two Exec statements:

delete-radius-rpmnew
delete-radius-rpmsave

These lines are sensible - the debian equivelent to the .rpm* files are called .dpkg-*

Also, /bin/find doesn't exist on Debian Wheezy (at least) - it's /usr/bin/find. Perhaps an Exec line (like this: Exec {path => ["/bin/", "/sbin/", "/usr/bin/", "/usr/sbin/"] }) in the params.init might be a better idea?

Hello,

I'm trying to use the module from puppet forge, version 0.4.3 and I am seeing the below error.

Unknown function warn at /etc/puppet/modules/freeradius/manifests/init.pp:16 on node

This is caused when control socket is enabled as per the below code.

class { 'freeradius':
  control_socket  => true,
  max_requests    => 4096,
  max_servers     => 4096,
  mysql_support   => true,
  utils_support   => true,
}

This is using puppet server and client 3.7

for the time being i've disabled the controls sockets.

thanks
Luke

I already knew that sites were added to sites-enabled directly and didn't care, but yesterday I discovered that this caused serious problem at least with Debian package management: It creates a symlink "default" in sites-enabled, which overrides a site named "default" created with this module by puppet. This is when the downtime starts.
A puppet run would not fix it, because puppet does not care of content if it is a symlink.
This is where the downtime gets permanent until you delete the symlink and run puppet again.

The freeradius devs advise/instruct to use links in sites-enabled:

#	Virtual hosts should be put into the "sites-available"
#	directory.  Soft links should be created in the "sites-enabled"
#	directory to these files.

From my point of view it would be better to create the file in sites-available and a symlink to it in sites-enabled, just as "anyone else". Are there any arguments for keeping the old behaviour?

A workaround is renaming the sites to unused names.