FreeRADIUS radiusd.conf file: edits reverting



  • 1.2-RC2 built on Fri Aug 17 17:46:06 EDT 2007

    I have FreeRADIUS installed - which was something of a trial as the service wouldn't run after installation via the GUI (I resorted to pkg_add and it appears to work correctly so far as local users added to FreeRADIUS are concerned). Anyhow, I need to get FreeRADIUS to authenticate against an LDAP server, so I needed to edit the FreeRADIUS configuration file. However…

    1. Status > services: stop freeradius service.
    2. Diagnostics > Edit file, load: /usr/local/etc/raddb/radiusd.conf, edit then save.
    3. Reboot.

    Repeat 2, and it appears that /usr/local/etc/raddb/radiusd.conf is back to its original state, ie unedited. Edit it again, save it, load it, and it's okay, but as soon as I reboot pfsense it's back to the virgin state.

    Any suggestions as to what might be wrong? Have I fundamentally misunderstood something? I have it in mind that all pfsense configuration is contained in a single XML file - does this include such things as the radiusd.conf file and is that why my changes are being overwritten when pfsense starts up?



  • @sheepthief:

    1.2-RC2 built on Fri Aug 17 17:46:06 EDT 2007

    I have FreeRADIUS installed - which was something of a trial as the service wouldn't run after installation via the GUI (I resorted to pkg_add and it appears to work correctly so far as local users added to FreeRADIUS are concerned).

    Interesting - I thought that was how it was installed in the first place - guess I should look at the installation scripts :) .

    Anyhow, I need to get FreeRADIUS to authenticate against an LDAP server, so I needed to edit the FreeRADIUS configuration file. However…

    1. Status > services: stop freeradius service.
    2. Diagnostics > Edit file, load: /usr/local/etc/raddb/radiusd.conf, edit then save.
    3. Reboot.

    Repeat 2, and it appears that /usr/local/etc/raddb/radiusd.conf is back to its original state, ie unedited. Edit it again, save it, load it, and it's okay, but as soon as I reboot pfsense it's back to the virgin state.

    Yep - it would be back in it's original state as the system reloads the radiusd.conf file using the file information contained it /usr/local/pkg/freeradius.inc . That is the file you need to modify in order to keep all of your configuration settings.

    Look at the configuration settings between the $conf = << <eod and="" eod="" flags="" -="" that="" is="" what="" written="" to="" the="" radiusd.conf="" file="" when="" system="" starts="" up.<br="">Hope this helps.

    gm…</eod>



  • @gmckinney:

    @sheepthief:

    1.2-RC2 built on Fri Aug 17 17:46:06 EDT 2007

    I have FreeRADIUS installed - which was something of a trial as the service wouldn't run after installation via the GUI (I resorted to pkg_add and it appears to work correctly so far as local users added to FreeRADIUS are concerned).

    Interesting - I thought that was how it was installed in the first place - guess I should look at the installation scripts :) .

    Well, I'd tried to add the package via the GUI; System > Packages method I fell foul of the gethostbyname_r undefined symbol issue (as mentioned elsewhere on the forums), so I resorted to doing it manually from the command-line.

    Anyhow, I need to get FreeRADIUS to authenticate against an LDAP server, so I needed to edit the FreeRADIUS configuration file. However…

    1. Status > services: stop freeradius service.
    2. Diagnostics > Edit file, load: /usr/local/etc/raddb/radiusd.conf, edit then save.
    3. Reboot.

    Repeat 2, and it appears that /usr/local/etc/raddb/radiusd.conf is back to its original state, ie unedited. Edit it again, save it, load it, and it's okay, but as soon as I reboot pfsense it's back to the virgin state.

    Yep - it would be back in it's original state as the system reloads the radiusd.conf file using the file information contained it /usr/local/pkg/freeradius.inc . That is the file you need to modify in order to keep all of your configuration settings.

    Look at the configuration settings between the $conf = << <eod and="" eod="" flags="" -="" that="" is="" what="" written="" to="" the="" radiusd.conf="" file="" when="" system="" starts="" up.<br="">Hope this helps.

    gm…</eod>

    Ah, I'd thought that /usr/local/pkg/freeradius.inc was only used during the installation of FreeRADIUS - thanks for clearing that up for me. So, this is normal behaviour then and not something unexpected? - I'll have to watch for that in future. Thanks for your help.



  • yea - in the freeradius.inc file there is a function called Freeradius_settings_resync which is where the conf file is created prior to re-initializing the freeradius server.  That function is what was biting you :) as it is called when you make changes to the freeradius settings and probably during the startup phase as well (although I have not checked that out yet).

    My interest in the FreeRadius package is to expand the capabilities - as it is now it is limited (and was so stated in the packages section as well) but I want to increase the capabilities to include most of the FreeRadius functionality, not the current limited version. :)

    gm…



  • @gmckinney:

    My interest in the FreeRadius package is to expand the capabilities - as it is now it is limited (and was so stated in the packages section as well) but I want to increase the capabilities to include most of the FreeRadius functionality, not the current limited version. :)

    Well, it turns out that I can't use this package as it stands - it's not compiled to include the functionality to query LDAP databases, so if you're thinking of adding that I'd be glad to hear it!



  • @sheepthief:

    @gmckinney:

    My interest in the FreeRadius package is to expand the capabilities - as it is now it is limited (and was so stated in the packages section as well) but I want to increase the capabilities to include most of the FreeRadius functionality, not the current limited version. :)

    Well, it turns out that I can't use this package as it stands - it's not compiled to include the functionality to query LDAP databases, so if you're thinking of adding that I'd be glad to hear it!

    Well - in looking at the existing package I can verify the current FreeRadius package does not have LDAP nor SQL functionality compiled.  I suspect there are other packages needed for both (openldap and mysql client come to mind).

    I did test to see if the realms section is functional and it is - what this means is you could setup an external FreeRadius server running on a complete system (pfsense is stripped down for firewall operation first and foremost) where you can compile the required packages that would allow FreeRadius to have all of it's functionality.  Then, you would use the realms capabilities of the FreeRadius package installed in the pfsense package section to communicate with the external FreeRadius system to access ldap databases (or mysql or other sql databases as well)…

    In using the FreeRadius package in the pfsense system in this manner you keep from introducing possible security holes in the pfsense system but still have the additional capabilities afforded by FreeRadius but of course this will require an additional host machine running the full FreeRadius system.

    Just a thought.

    gm...



  • I know this is a rather old thread, but I have direct experience of this. FreeBSD doesn't provide a FreeRADIUS package with OpenLDAP functionality compiled in. I should know - I'm the maintainer of the net/freeradius port / package on FreeBSD.

    All the non-default options in the port add extra dependencies - KERBEROS needs MIT Kerberos 5, HEIMDAL needs Heimdal Kerberos, LDAP needs an OpenLDAP client, MYSQL needs a MySQL client, PGSQL needs a PostgreSQL client, FIREBIRD needs the Firebird client and EXPERIMENTAL, SNMP needs net-snmp 4 (unfortunately it doesn't work with net-snmp 5 because the FreeBSD port doesn't build net-snmp with the ucd-snmp compatibility option), EDIR needs LDAP and EXPERIMENTAL needs python. Because some of these are either/or options (you can have MIT Kerberos or Heimdal installed on a machine but not both), or there's several possible versions in ports (true for all of OpenLDAP, MySQL, PostgreSQL and python) these options have to remain off by defaults so they're off in the FreeBSD package builds.

    At the request of someone working on some pfSense related stuff, I did create the net/freeradius-mysql port, and built a 6.2-RELEASE package which I emailed to the requestor. Further slave ports really aren't on, however - I can't reasonably clutter the ports tree with freeradius-ldap port and a freeradius-mysql-ldap port.

    If you want a FreeRADIUS package with other options, simply:
    cd /usr/ports/net/freeradius
    make config
    make package

    on a FreeBSD 6.2-RELEASE i386 machine or virtual machine.

    Unfortunately, changes in the ports tree (to do with the change to autoconf 2.61) mean that you can't build the latest version of the net/freeradius port with the rest of the ports tree as it was at the time of 6.2-RELEASE. You can, of course, c(v)sup the entire ports tree and build the port on a 6.2-RELEASE machine, but it's possible then to finish up with FreeRADIUS depending on later versions of some ports than other pfSense packages. As an alternative, you may get away with changing the USE_AUTOTOOLS line of /usr/ports/net/freeradius/Makefile to refer to autoconf:259 (it's around line 41, depending on exactly which version you have), then build on an otherwise unmodified 6.2-RELEASE ports tree, but I can't guarantee that will work.

    The FreeRADIUS project has stated its intention to move FreeRADIUS 1.x to maintenance only mode as soon as 2.x is released - see here for details. If you're going to do any major work with FreeRADIUS in pfSense, it may make more sense to work with 2.x. A 2.0.0-pre2 port is in the process of going through final checks before being committed to the FreeBSD ports tree, but it just missed the deadline to be included in the upcoming FreeBSD 6.3-RELEASE.

    There have been a lot of changes between 2.0.0-pre2 and FreeRADIUS' CVS HEAD, but it's not really practical to produce a port against a CVS snapshot. Hopefully the FreeRADIUS team will release another prerelease or a beta release soon.

    If you really have a need to refer to an LDAP directory, I'd question whether pfSense is the right place to be running FreeRADIUS - especially if LDAP is going to be used for authentication so the LDAP details in FreeRADIUS give access to passwords in the directory. I wouldn't want any passwords that give access to sensitive information in the LDAP directory in my firewall.

    If you have a machine running an LDAP server, can't you install FreeRADIUS there? If you want or need separation from the OpenLDAP server, and it's a FreeBSD box, use a jail (to make this easy, consider ezjail).

    David



  • I've started working on the Freeradius package for PFSense I was going to add in MySQL, PostgreSQL, and OpenLDAP. When creating a package using 'make package' it doesn't seem to include the dependencies. So I started making packages of all the dependencies but got stuck when it told the package was already installed. I first had to remove the package and all it dependents before I could run 'make package' on them. Is there anyway to run 'make package' without having to uninstall them first?



  • make package-recursive



  • Thanks! I tried 'make package-recursive' as you recommended and it worked perfect!



  • Hopefully you have what you need now. For reference, the various targets for make are documented in the comments of /usr/ports/Mk/bsd.port.mk

    If you're going to make package-recursive you might want to make config-recursive first to ensure that your build doesn't stop part way through asking for options of other ports. That said, there's a strong argument on a system like pfSense for leaving the ports on which you depend with their default options unless it's absolutely unavoidable. This avoids potential problems with one pfSense package needing, say, openldap-client built with one set of options, whilst FreeRADIUS needs different and conflicting options.

    I intend to hang around as I'm likely to be buying hardware shortly to replace my commercial firewall with pfSense. The commercial firewall has developed hardware issues with its Ethernet switch and is looking like a dead-end product now and, as I have no hardware warranty remaining, it probably isn't worth repairing. For now, I'm running a pfSense Live CD and floppy setup on an ancient PC recovered from my parts bin. Whilst I know this is off-topic in this particular thread, one of today's tasks is to look at:

    ALIX 2C3. I know about the lack of VLANs in 1.2 - I'll create a custom pfSense 1.2 with the FreeBSD 6.3 changes to if_vr.c back-ported if I go this way; I have the developer's ISO bootstrapping in VMware Workstation 6 as I write this.

    A Mini-ITX system with, most likely, a VIA based board. The main advantages of going with this option are the ability to run Snort and the Padlock features of the processor for fast AES (which is potentially very useful for IPsec). Why do so many Mini-ITX boards have grotty Realtek NICs - I'd much prefer em (Intel Gigabit) or bge (Broadcom Gigabit) devices. I could always put a PCI-X Intel Pro 1000/MT Dual board in the PCI slot, but that adds £100 to the parts bill and gives a larger and more power-hungry machine.

    An inexpensive 1U rack mount dual core Xeon box (probably Dell) which could eventually go in the same rack as the dual quad core Penryn Xeon box (almost certainly a Dell Poweredge 2950 III running FreeBSD 7.0 amd64) that I'm looking to install in a few months time. I think this is probably overkill for my requirements, not least as I don't believe in putting important data (like a replicant of my main MySQL server, a replicant of my LDAP server or rsynced backups) on a firewall. However, this may be better value than trying to build a powerful Mini-ITX system even though it will take more space and use more power.

    David



  • Do you have a patch against 6.2 for the ALIX?  We have been hunting for one.



  • @sullrich:

    Do you have a patch against 6.2 for the ALIX?  We have been hunting for one.

    Not yet - but if I buy an ALIX and create one, I will, of course, send it in.

    ALIX support is available in the latest m0n0wall betas (which are, unless I'm completely misremembering, 6.2-RELEASE based), and the VLAN related stuff seems to be, on what I admit is a relatively cursory inspection, to be available in the RELENG_6 version of if_vr.c, so hopefully the patches aren't too difficult to work out. The RELENG_6_2 man page for altq(4) indicates that ALTQ support is already in the vr(4) driver, which is one thing that won't need doing.

    I was half hoping that someone had already done the necessary work. I have plenty of other things to be getting on with and no desire to repeat a kernel hacking exercise that someone else may have already done. Unfortunately, nobody seems to have put their heads above the parapet with a patch set for pfSense yet.

    Are there any plans to move pfSense over to RELENG_6_3? That would certainly sort out VLAN support for the VIA Rhine ethernet controller as used in the ALIX, but I appreciate that this is not likely to happen until pfSense 1.3, whilst FreeBSD 6.3-RELEASE is likely to be a few weeks away yet.

    As you can probably tell, I'm pretty comfortable with FreeBSD and FreeBSD ports/packages. I'm far from a novice with pf. However, my experience with pfSense is fairly limited.

    David



  • For some reason the patch is not in m0n0's repo.

    We already have 1.3 working on 6.3.  Alphas/Betas will start once 1.2 is released.



  • I used the pkg_add recursive compiling in MySQL and PostgresQL and the result was the following packages with their dependencies shown below. It seems like quite a few dependencies to be adding to a firewall so I have decided against proceeding.

    01/01/2008  01:23 AM          319,174 autoconf-2.61_2.tbz
    01/01/2008  01:24 AM            3,911 autoconf-wrapper-20071109.tbz
    01/01/2008  01:23 AM        1,081,905 freeradius-1.1.7_2.tbz
    01/01/2008  01:23 AM            31,655 gdbm-1.8.3_3.tbz
    01/01/2008  01:24 AM        1,989,962 gettext-0.16.1_3.tbz
    01/01/2008  01:23 AM          236,597 gmake-3.81_2.tbz
    01/01/2008  01:24 AM            28,103 help2man-1.36.4_1.tbz
    01/01/2008  01:24 AM        1,481,060 libiconv-1.11_1.tbz
    01/01/2008  01:24 AM            30,211 libltdl-1.5.24.tbz
    01/01/2008  01:23 AM          341,974 libtool-1.5.24.tbz
    01/01/2008  01:24 AM            82,254 m4-1.4.9,1.tbz
    01/01/2008  01:23 AM          883,895 mysql-client-5.0.51.tbz
    01/01/2008  01:24 AM            14,464 p5-gettext-1.05_1.tbz
    01/01/2008  01:23 AM        10,898,876 perl-5.8.8_1.tbz
    01/01/2008  01:24 AM        1,725,137 postgresql-client-8.1.10.tbz

    I have been toying with the idea of a customized version of PFSense that would retain its package support. However it would focus as an Application Server Appliance rather than as a firewall. Kind of like how Askozia is to m0n0wall except maintaining the PFSense package system this would allow for a much broader purpose. An application server would be a better place for an extended FreeRadius package with multiple database vendor support.

    The pfsense blog at http://blog.pfsense.org/ shows a hint of interest in this area 'Using pfSense as a Server Only' perhaps someone else is already working on this. If so I would like to jump on board.



  • Many of those are build time rather than run time dependencies. If you issue pkg_info -r 'freeradius-*' you'll get a listing of the run-time dependencies.

    On my main FreeBSD box (note - not a pfSense box):

    [david@titanium ~]$ pkg_info -r 'freeradius-*'
    Information for freeradius-2.0.0:

    Depends on:
    Dependency: openssl-0.9.8g
    Dependency: openldap-client-2.3.40
    Dependency: python25-2.5.1_1
    Dependency: perl-5.8.8_1
    Dependency: libltdl-1.5.24
    Dependency: libiconv-1.11_1
    Dependency: gettext-0.16.1_3
    Dependency: mysql-client-5.0.51
    Dependency: gdbm-1.8.3_3
    Dependency: gmake-3.81_2

    Note that this is the current version of the net/freeradius2 port which is in the process of being committed to the FreeBSD ports tree - since I last posted FreeRADIUS 2.0.0 has been released, and FreeRADIUS 1.x is now in 'maintenance' mode with little if any further development.

    OpenLDAP and MySQL are dependencies because I explicitly enabled that support - it's not default.

    There are three run dependencies for net/freeradius2 there that aren't in net/freeradius (FreeRADIUS 1.1.7). They are python (rlm_python is stable in 2.0 but experimental in 1.x, so it's not built by default in 1.x), gmake (which is needed to run the bootstrap Makefile in raddb to build some default certificates - I may investigate patching the Makefile to make it work with BSD make) and OpenSSL (which is there because I use the up to date OpenSSL from ports rather than the older one in the base system).

    In my opinion, any future work done on FreeRADIUS should be done with FreeRADIUS 2 - the extensive rewrites mean it's a much better product to work with. However, the footprint is a little larger than FreeRADIUS 1.x.

    In the future, the python dependency could be made optional (though this really needs bsd.options.mk to be available, which can't happen until the ports tree drops support for FreeBSD 6.2 and earlier versions). Making the perl dependency optional is really tricky - more than rlm_perl uses it (for example, radsqlrelay is written in perl - though I've yet to add a necessary patch to the port to make that work correctly in FreeBSD) and there's no configure flag to turn off the perl requirement. Really, FreeRADIUS should always have perl available.

    We both seem to be of a mind that there comes a point where it's inappropriate to run a complex server on a firewall.

    I've decided that I will almost certainly buy a Dell T200 for my permanent pfSense setup; it can go in the rack that we're looking to install soon. I did price up a mini-ITX system, and I was going to pay as much for a 1.7GHz / 1GB RAM mini-ITX with only a single Gigabit interface that doesn't support ALTQ (and hence traffic shaping) as for a dual core 2.33GHz / 2GB RAM 1U rack machine with two bge interfaces (which are Broadcom Gigabit devices with ALTQ support). The power of the Dell should give me more than enough horsepower for Snort.

    David


Log in to reply