Hi,

.. So would you suggest to rather use 2.0.4 instead?

SNMP hasnt worked properly since about 1.0.5

I might want to use the statistics given in DialupAdmin. And also PostgreSQL IP-Pool should work.

I'd go for 2.0.5 - you'll need whatever dependencies you are attempting to use - want postgres? you'll need to ensure postgresql development files/headers are installed etc. of course, if you build the package on a 'build server' and put it on other systems - then all they [run systems] need are the main packages - postgresql-server etc etc and no development stuff. alan

Where can I check wether postgresql support is compiled in or not?? Thanks Leander Leander S. schrieb:

I'm now trying to compile 2.0.5 ... downloaded it, extracted it, and executeted ./configure --help --> but I couldn't find an option saying SQL support or postgres or anything ... could you give me a clue about the syntax?

thx

A.L.M.Buxey@lboro.ac.uk schrieb:

...

Hi,

...

.. So would you suggest to rather use 2.0.4 instead?

SNMP hasnt worked properly since about 1.0.5

...

I might want to use the statistics given in DialupAdmin. And also PostgreSQL IP-Pool should work.

I'd go for 2.0.5 - you'll need whatever dependencies you are attempting to use - want postgres? you'll need to ensure postgresql development files/headers are installed etc.

of course, if you build the package on a 'build server' and put it on other systems - then all they [run systems] need are the main packages - postgresql-server etc etc and no development stuff.

alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Leander S. wrote:

I'm now trying to compile 2.0.5 ... downloaded it, extracted it, and executeted ./configure --help --> but I couldn't find an option saying SQL support or postgres or anything ... could you give me a clue about the syntax?

You install the relevant SQL libraries and header files. Then type "./configure". It would also help to read the output of "configure" and "make". Perhaps if it's building SQL modules, there would be references to "SQL". ? Alan DeKok.

Hi Alan, I know about radius -X ... I already setted up the version 1.1.7 succesfully ... but now I'm working on almost complety revised version 2.0.5 ... so SQL configs are different for me and I might made some mistakes there so that the radius -X is not showing me some pg code ... ;/ ____ Btw.: ./configure --with-your-personal-options | grep WARNING --> There is nothing saying anything about sql , or pg or postgres in ./configure --help ... You may want to give me an example especialy for postgres ?! Would be great. --> I also tryed: ./configure --with-postgresql=YES --enable-postgresql=YES --with-rlm-postgresql-lib-dir=/usr/local/lib/ --with-rlm-postgresql-include-dir=/usr/local/lib/ --> But I haven't had more luck than before .. and also no more WARNING messages to read than I've had before .. so there might be something wrong ... ____ But anyway .. here's how I used to run it usually ... because you said it trys to build as much modules as possible if the neccessary software stuff like postgresql-server/client is already preinstalled ... so postgres support for freeradius should work also ... but .. sadly .. it won't do it yet for me ... ;) root /usr/src/freeradius-server-2.0.5 # ./configure | grep WARNING config.status: WARNING: ./Make.inc.in seems to ignore the --datarootdir setting config.status: WARNING: ./src/include/build-radpaths-h.in seems to ignore the --datarootdir setting chmod: check-radiusd-config: No such file or directory configure: WARNING: silently not building rlm_eap_ikev2. configure: WARNING: FAILURE: rlm_eap_ikev2 requires: libeap-ikev2 EAPIKEv2/connector.h. configure: WARNING: the TNCS library isn't found! configure: WARNING: silently not building rlm_eap_tnc. configure: WARNING: FAILURE: rlm_eap_tnc requires: -lTNCS. configure: WARNING: silently not building rlm_krb5. configure: WARNING: FAILURE: rlm_krb5 requires: krb5. configure: WARNING: silently not building rlm_ldap. configure: WARNING: FAILURE: rlm_ldap requires: libldap_r ldap.h. configure: WARNING: silently not building rlm_python. configure: WARNING: FAILURE: rlm_python requires: python-binary. configure: WARNING: oracle headers not found. Use --with-oracle-home-dir=<path>. configure: WARNING: silently not building rlm_sql_oracle. configure: WARNING: FAILURE: rlm_sql_oracle requires: oci.h. root /usr/src/freeradius-server-2.0.5 # ... ^^ which looks fine for me so far ... because I only need PostgreSQL ... not Oracle or MySQL. but if I now go ahead and do: # ./configure, gmake, gmake install and finally run radius -X it shows me not even one time anything about pg or postgres module ...: root /usr/src/freeradius-server-2.0.5 # radiusd -X FreeRADIUS Version 2.0.5, for host x86_64-unknown-freebsd7.0, built on Jun 23 2008 at 02:01:51 Copyright (C) 1999-2008 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 v2. Starting - reading configuration files ... including configuration file /usr/local/etc/raddb/radiusd.conf including configuration file /usr/local/etc/raddb/proxy.conf including configuration file /usr/local/etc/raddb/clients.conf including configuration file /usr/local/etc/raddb/snmp.conf including files in directory /usr/local/etc/raddb/modules/ including configuration file /usr/local/etc/raddb/modules/policy including configuration file /usr/local/etc/raddb/modules/acct_unique including configuration file /usr/local/etc/raddb/modules/unix including configuration file /usr/local/etc/raddb/modules/chap including configuration file /usr/local/etc/raddb/modules/preprocess including configuration file /usr/local/etc/raddb/modules/expiration including configuration file /usr/local/etc/raddb/modules/mac2vlan including configuration file /usr/local/etc/raddb/modules/mschap including configuration file /usr/local/etc/raddb/modules/ippool including configuration file /usr/local/etc/raddb/modules/files including configuration file /usr/local/etc/raddb/modules/krb5 including configuration file /usr/local/etc/raddb/modules/passwd including configuration file /usr/local/etc/raddb/modules/radutmp including configuration file /usr/local/etc/raddb/modules/attr_rewrite including configuration file /usr/local/etc/raddb/modules/echo including configuration file /usr/local/etc/raddb/modules/etc_group including configuration file /usr/local/etc/raddb/modules/pap including configuration file /usr/local/etc/raddb/modules/realm including configuration file /usr/local/etc/raddb/modules/pam including configuration file /usr/local/etc/raddb/modules/always including configuration file /usr/local/etc/raddb/modules/exec including configuration file /usr/local/etc/raddb/modules/logintime including configuration file /usr/local/etc/raddb/modules/sql_log including configuration file /usr/local/etc/raddb/modules/smbpasswd including configuration file /usr/local/etc/raddb/modules/sradutmp including configuration file /usr/local/etc/raddb/modules/counter including configuration file /usr/local/etc/raddb/modules/ldap including configuration file /usr/local/etc/raddb/modules/expr including configuration file /usr/local/etc/raddb/modules/attr_filter including configuration file /usr/local/etc/raddb/modules/checkval including configuration file /usr/local/etc/raddb/modules/digest including configuration file /usr/local/etc/raddb/modules/detail including configuration file /usr/local/etc/raddb/modules/detail.log including configuration file /usr/local/etc/raddb/modules/mac2ip including configuration file /usr/local/etc/raddb/eap.conf including configuration file /usr/local/etc/raddb/sql.conf including configuration file /usr/local/etc/raddb/sql/postgresql/dialup.conf including configuration file /usr/local/etc/raddb/sql/postgresql/counter.conf including configuration file /usr/local/etc/raddb/sqlippool.conf including configuration file /usr/local/etc/raddb/sql/postgresql/ippool.conf including configuration file /usr/local/etc/raddb/policy.conf including files in directory /usr/local/etc/raddb/sites-enabled/ including configuration file /usr/local/etc/raddb/sites-enabled/default including configuration file /usr/local/etc/raddb/sites-enabled/inner-tunnel including dictionary file /usr/local/etc/raddb/dictionary [...] no more sql infomation ^^ postgresql seems not even to be loaded when radius starts ... [...] a step further I noticed there is even no module in: root /usr/src/freeradius-server-2.0.5 # ls -lach /usr/local/etc/raddb/modules/ total 84 dr--r--r-- 2 root wheel 1.0K Jun 23 01:36 . dr--r--r-- 7 root wheel 1.0K Jun 23 01:36 .. -r--r--r-- 1 root wheel 507B Jun 23 01:36 acct_unique -r--r--r-- 1 root wheel 465B Jun 23 01:36 always -r--r--r-- 1 root wheel 1.0K Jun 23 01:36 attr_filter -r--r--r-- 1 root wheel 1.4K Jun 23 01:36 attr_rewrite -r--r--r-- 1 root wheel 182B Jun 23 01:36 chap -r--r--r-- 1 root wheel 1.4K Jun 23 01:36 checkval -r--r--r-- 1 root wheel 2.9K Jun 23 01:36 counter -r--r--r-- 1 root wheel 1.8K Jun 23 01:36 detail -r--r--r-- 1 root wheel 1.7K Jun 23 01:36 detail.log -r--r--r-- 1 root wheel 318B Jun 23 01:36 digest -r--r--r-- 1 root wheel 3.3K Jun 23 01:36 echo -r--r--r-- 1 root wheel 706B Jun 23 01:36 etc_group -r--r--r-- 1 root wheel 809B Jun 23 01:36 exec -r--r--r-- 1 root wheel 597B Jun 23 01:36 expiration -r--r--r-- 1 root wheel 601B Jun 23 01:36 expr -r--r--r-- 1 root wheel 606B Jun 23 01:36 files -r--r--r-- 1 root wheel 2.2K Jun 23 01:36 ippool -r--r--r-- 1 root wheel 196B Jun 23 01:36 krb5 -r--r--r-- 1 root wheel 4.9K Jun 23 01:36 ldap -r--r--r-- 1 root wheel 1.1K Jun 23 01:36 logintime -r--r--r-- 1 root wheel 725B Jun 23 01:36 mac2ip -r--r--r-- 1 root wheel 394B Jun 23 01:36 mac2vlan -r--r--r-- 1 root wheel 2.1K Jun 23 01:36 mschap -r--r--r-- 1 root wheel 684B Jun 23 01:36 pam -r--r--r-- 1 root wheel 613B Jun 23 01:36 pap -r--r--r-- 1 root wheel 1.2K Jun 23 01:36 passwd -r--r--r-- 1 root wheel 604B Jun 23 01:36 policy -r--r--r-- 1 root wheel 1.7K Jun 23 01:36 preprocess -r--r--r-- 1 root wheel 1.5K Jun 23 01:36 radutmp -r--r--r-- 1 root wheel 891B Jun 23 01:36 realm -r--r--r-- 1 root wheel 402B Jun 23 01:36 smbpasswd -r--r--r-- 1 root wheel 2.0K Jun 23 01:36 sql_log -r--r--r-- 1 root wheel 489B Jun 23 01:36 sradutmp -r--r--r-- 1 root wheel 586B Jun 23 01:36 unix root /usr/src/freeradius-server-2.0.5 # so it might be still missed .. but what part is missed to get postgresql support? I already do have PostgreSQL Server 8.3 compiled and successfully running and I also do have PostgreSQL Client 8.1 also already installed from binary to my FreeBSD.. so WTF? ;) ?? Thx a lot regards, Leander A.L.M.Buxey@lboro.ac.uk schrieb:

Hi,

...

I'm now trying to compile 2.0.5 ... downloaded it, extracted it, and executeted ./configure --help --> but I couldn't find an option saying SQL support or postgres or anything ... could you give me a clue about the syntax?

run ./configure

it will spew out a lot of WARNINGs if it cannot find required packages....so you can either read the output, or just do

./configure --with-your-personal-options | grep WARNING

(where, of course, --with-your-personal-options isnt a real flag but is an example! you put your desired flags there as per ./configure --help)

by default, freeradius will try to build as many 3rd party items as it can - if it cant find the required development headers/includes etc then it wont compile the support in and will simply throw out a warning. simple as that. if you do compile freeradius and dont have, eg mysql-devel stuff installed, then the radiusd will work fine - but just wont accept or work with any mysql stuff.

alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Hi,

Hi Alan,

I know about radius -X ... I already setted up the version 1.1.7 succesfully ... but now I'm working on almost complety revised version 2.0.5 ... so SQL configs are different for me and I might made some mistakes there so that the radius -X is not showing me some pg code ... ;/

actuually, the SQL is very very similar...its one of the least changed parts. alan

David Wood wrote:

The correct way ahead with the FreeRADIUS SNMP code is widely acknowledged to be a rewrite using AgentX - however the new statistics code may turn out to be a better option. I wonder if the current SNMP code will be retired now that the statistics code is available.

The current SNMP code will be deleted before the next release. The goal by the end of the year is either to implement AgentX in the server, OR there will be a separate program that does AgentX on one side, and the RADIUS statistics on the other. Alan DeKok.

Hi Leander, In message <485EF043.70208@gmx.net>, Leander S. <leander.schaefer@gmx.net> writes

Thank you very much for your work David! But I rather want to compile it by myself, because:

a) I don't want to update all my ports, because than I am "supposed" to update my RELEASE version of FreeBSD to an STABLE version and reinstall all packages and re-check my configuration files in etc ... bla bla ... (it's a production server)

What I was suggesting is nothing like as drastic as that. You do not need to update your operating system at all. You can leave your OS on any supported version for the ports tree - that's any -STABLE branch that isn't End of Life, or any -RELEASE that isn't End of Life. 7.0-RELEASE is supported. The ports tree only drops support for a particular version once that version of FreeBSD reaches its End of Life date, which is when the FreeBSD Security Officer ceases security support for that release or branch of the operating system. You only need to update those ports that have changed - not every port on the system. portupgrade or portmaster make the task of keeping your ports up to date easy. I recommend portmaster where possible, as it has no dependencies (it's a shell script, rather than the Ruby of portupgrade), also it's much more modern and better maintained. However, it lacks some of the features of portupgrade. The only reason that I warned you that a substantial portion of your ports would need to be rebuilt (but not necessarily upgraded to a new version) is because the version of gettext in the ports tree has been upgraded. This means the version of the libintl shared library has been bumped - and the only way to ensure everything is using that new version is to rebuild everything that depends on gettext. You should get into the habit of reading /usr/ports/UPDATING every time you upgrade your ports tree before you rebuild or upgrade anything; that is where you are alerted to anything you need to be aware of - like the change in gettext and what it means. As a system administrator, you can choose your own trade off between how often you update your ports tree and upgrade your ports. You might get away with cherry picking one port and upgrading just that - but that gets increasingly less likely to work the longer it is since you rebuilt your ports tree. Eventually important build dependencies are too old and need to be rebuilt, or a new version of a port requires a feature or bug fix in a dependency that you haven't built, at which point you really need to bring all your ports up to date. If you haven't brought your ports up to date for some time, you may then be facing a huge number of updates. Arguably the more conservative option is to update your ports on a schedule, so that the process of change is more gradual. There's a philosophical point here. The ultra conservative option is that adopted by the likes of RedHat Enterprise Linux. RHEL ships with particular versions of third party software that are essentially frozen for the lifetime of a particular version of the OS. RedHat takes it upon themselves to back port any necessary fixes. This stops the system administrator being surprised by changes in third party software as they keep their system up to date. However, it means that the versions used get increasingly out of date with respect to releases from the third party vendors. The problem you're experiencing may have been fixed in a later version than is supported for your particular OS. In other words, the ultra conservative option might actually be a liability - because you can finish up building software by yourself to get fixes that you need. Some of the versions supplied on old but still maintained versions of these operating systems are ancient - look at the number of threads on this mailing list that finish up with 'that version is old and buggy - upgrade'. It also means that when you do upgrade your OS, all your software goes through a significant version jump. FreeBSD doesn't have the developer and maintainer time available to keep a versioned ports tree in the RedHat Enterprise Linux type model. There is one ports tree. You can try to cherry pick individual ports to upgrade, but if you come unstuck, you will probably receive no support beyond the advice to 'upgrade to the latest version of the ports tree and try again'. To help the system administrator, ports are not allowed to touch configuration files that the user has changed when you upgrade them. The only problem comes if the upgraded port doesn't understand your customised configuration for an old version - but that's a problem with the ported software, not FreeBSD or the ports tree. My personal strategy to keep proper version control of configurations, and to back-port changes in port configurations when I upgrade from one version to another is to use Subversion. I keep sample port configurations in vendor branches in Subversion, and svn merge any changes back to my live configurations. See the bit in the Subversion book (available free online) about Vendor Branches for more details. There's no need to use a version control system. You can handle this any way you like, including ignoring any changes in the sample configurations of your ports until you hit problems - though I do not recommend this, not least as some of the bug fixes or new functionality may depend on changes in the sample configuration. Alan de Kok has recommended keeping FreeRADIUS configurations in a version control system several times to my memory. Clean copies of the sample configuration are installed elsewhere for your reference - if there's one or two files, they may be installed in /usr/local/etc with .sample or .example added to the file name. As FreeRADIUS has such an extensive configuration, it puts the sample configuration in its examples folder - by default, that's usr/local/share/example/raddb. There is a particular problem for the 2.0.3 to 2.0.5 upgrade that I'm solving once and once only in this version. Historically the behaviour of the FreeRADIUS port on uninstallation has been to go through /usr/local/etc/raddb and remove any individual files that are the same as the sample file installed. What is left behind in this system are just the files you have changed. When you install a new version of the port, any missing files in /usr/local/etc/raddb are copied from the sample configuration. The advantage of this is that you get updated versions of files you haven't customised. That is also a disadvantage - in that you finish up with a configuration based on mixed versions of sample files that may have weird compatibility issues. With the move to modules having their own configuration files in 2.0.5, the old behaviour is untenable - anyone who has configured the server would finish up with two configurations for the modules (one in radiusd.conf, one in the modules directory), and the configurations in the modules directory not linked in to the server. That is confusing, to put it mildly. From 2.0.5 onwards, the port will remove the entire configuration when it is uninstalled - but only if it's unmodified (it does make allowance for the certs folder being bootstrapped). If any part of the configuration has been modified, it is left alone. On installation, the port installs a clean configuration if you don't already have one in /usr/local/etc/raddb - otherwise it does nothing. However, I can't change the behaviour of older versions of the port on uninstallation - they will remove unmodified files in /usr/local/etc/raddb. The only way out of this is a message in /usr/ports/UPDATING to tell users to back up their configuration (or move it to another location than the default) whilst they upgrade the port. After upgrading to 2.0.5 (or later), you can then delete the newly installed configuration in /usr/local/etc/raddb and put their old configuration back. It's a one-time operation - the problem will not recur because of changing the behaviour of the port. If you land up with a partial configuration, you still have your changed files; the problem is just missing unchanged files. You can try to cherry pick individual ports to upgrade, but this can be problematic. There isn't sufficient effort available within the FreeBSD project to branch the ports tree. In particular, there is no notion of -RELEASE branches of the ports tree. FreeBSD adopts a different model to the likes of RedHat Enterprise Linux, where RedHat takes on the support of the versions of third party software they shipped. The vendor back-ports security patches and any essential bug fixes to the versions they shipped. This is a conservative option, in that you won't be surprised by changes in third party software, but it leads to increasing divergence from the 'state of the art' in that software. To help reduce the overhead of updating ports, no port is allowed to touch configuration files that the user has changed.

b) I might need to upgrade FreeRADIUServer in future ... and _only_ FreeRADIUServer .. so it might be a good exercise for me to get know about how to compile FreeRADIUServer and also of the dependencies I'll need in my case to be a little more independent and flexible of the provided binary packages of FreeBSD.

I suggest not using the binary packages - I'm talking about ports really. You can't use a binary package if you want PostgreSQL support. FreeRADIUS is relatively awkward to build correctly on FreeBSD. FreeBSD uses -pthread for threading libraries. You should not use -lpthread on FreeBSD, as the toolchain and dynamic linker do the right thing with -pthread alone. The issue here is that there are several threading libraries on FreeBSD (up to three, depending on the OS version) and you should leave the dynamic loader to follow its configuration rather than force dependency on libpthread. files/patch-pthread in the port patches three Makefile.in files to fix this, which then need rebuilding with autoconf. It also patches the Makefile.in for rlm_python to deal with libpython being threaded by default on FreeBSD - that really needs rebuilding with autoconf, too. I have offered this patch to the FreeRADIUS developers, but Nicolas Baradakis rejected it - if I remember rightly with a comment along the lines of not wanting to obfuscate the autoconf stuff for one operating system. I had hoped that the patch was clear, transparent and properly commented <sniff>. I hereby offer it again - http://tinyurl.com/6ezh7e will bring up a clean copy of the patch from FreeBSD's CVSweb that should apply cleanly against FreeRADIUS HEAD. I would be very grateful if this was applied to the FreeRADIUS CVS. Maybe I should open a bug for it on bugs.freeradius.org. I'm going to leave it out of the instructions below, because it's rather tricky to get the autoconf port working outside the ports framework. You must use GNU make, not BSD make - this can come from the devel/gmake port. BSD make has a different syntax for conditionals that is incompatible with FreeRADIUS's makefiles. configure needs quite a few arguments passed to it to be compliant with hier(7) and to find all the libraries. Your inability to build the PostgreSQL module indicates you haven't understood this, despite the advice you have been given several times. After untarring the FreeRADIUS 2.0.5 tarball and changing directory to the root of the untarred tarball, these steps are roughly what you need: LDFLAGS="-L/usr/local/lib -pthread" ; \ CFLAGS+="-I/usr/local/include -L/usr/local/lib" ; \ ./configure --prefix=/usr/local --libdir=/usr/local/lib \ --localstatedir=/var --with-docdir=/usr/local/share/doc/freeradius \ --with-logdir=/var/log \ --with-openssl-includes=/usr/local/include/openssl \ --with-openssl-libraries=/usr/local/lib gmake install You must add --with-pic to the first command if using FreeBSD amd64. You should omit the two openssl lines if you don't have the OpenSSL port included. I don't recommend this - I really do believe it's better to use the port. Best wishes, David -- David Wood david@wood2.org.uk