We are now in feature freeze for 3.0. The configuration format and behaviour for 3.0 will be stable between now and the final release. If you are planning on deploying 3.0 and have an existing 2.x.x configuration you were planning to migrate when the 3.0 is released, now would be a good time to try that, and to report any issues or problematic behaviour changes you notice. To provide a single point to test against, the release_3_0_0_rc0 tag has been created. Features and behaviours changes since release_3_0_0_beta1: * Empty xlat expansions are no longer substituted with "_". * Empty string expansions are no longer treated as failures, though actual failures and invalid operations will continue to bubble up and be translated into return codes. This is a change from 2.x.x where they were ignored. * Update sections support both types of exec, those which use the output of the program to create an attribute value, and those which use the output to create multiple value pairs. * Config item names have now been unified. In most cases the server will tell you the new name of the config item. * rlm_ldap now only registers LDAP-Group for the default instance. It used to register it for every instance which caused inconsistent behaviour. * New raddb structure. See raddb/README.rst for details. * Support for ${.:instance} which returns the instance name of a section and ${.:name} which returns the name of a section. Useful when used with relative paths. * Add support for bulk loading dynamic clients from LDAP. * Don't re-add default symlinks in raddb/sites-enabled/ raddb/mods-enabled/ Bug fixes: * Attribute instance selection [<n>] [#] [*] have been re-added to the xlat parser. * PCRE headers and libraries are now detected in a wider range of locations. * Symbols for PCRE drop in functions are now used in preference to posix functions, previously they weren't and this caused segfaults. * Fixes in the FreeTDS driver to avoid double frees. * Fix list to list copies in update sections. * Fix exec in update statements. * Fix use of double quoted strings in radclient -f files. * Many packaging fixes and cleanups. * Send Access-Rejects when using radsec. * Various radsec fixes to avoid crashes. * -HUP now works again. * Don't wait on execs to finish if they're marked as wait = 'no'. * Remove support for ranges in comparisons with NAS-Port-ID, these were broken, duplicative, and caused crashes. * Don't crash when parsing 64bit integer values from text * Expand ${...} before parsing conditions * Fix foreach * Be more lenient about MS-CHAP identity mismatches. The tarball is available here: https://github.com/FreeRADIUS/freeradius-server/archive/release_3_0_0_beta1.... Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On Thu, Jul 11, 2013 at 7:28 PM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
We are now in feature freeze for 3.0. The configuration format and behaviour for 3.0 will be stable between now and the final release.
If you are planning on deploying 3.0 and have an existing 2.x.x configuration you were planning to migrate when the 3.0 is released, now would be a good time to try that, and to report any issues or problematic behaviour changes you notice.
To provide a single point to test against, the release_3_0_0_rc0 tag has been created.
Features and behaviours changes since release_3_0_0_beta1:
... The tarball is available here:
https://github.com/FreeRADIUS/freeradius-server/archive/release_3_0_0_beta1....
Did you mean https://github.com/FreeRADIUS/freeradius-server/archive/release_3_0_0_rc0.ta... -- Fajar
On 11 Jul 2013, at 14:09, "Fajar A. Nugraha" <list@fajar.net> wrote:
On Thu, Jul 11, 2013 at 7:28 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote: We are now in feature freeze for 3.0. The configuration format and behaviour for 3.0 will be stable between now and the final release.
If you are planning on deploying 3.0 and have an existing 2.x.x configuration you were planning to migrate when the 3.0 is released, now would be a good time to try that, and to report any issues or problematic behaviour changes you notice.
To provide a single point to test against, the release_3_0_0_rc0 tag has been created.
Features and behaviours changes since release_3_0_0_beta1:
...
The tarball is available here: https://github.com/FreeRADIUS/freeradius-server/archive/release_3_0_0_beta1....
Did you mean https://github.com/FreeRADIUS/freeradius-server/archive/release_3_0_0_rc0.ta... ?
Yes. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Did you mean https://github.com/FreeRADIUS/freeradius- server/archive/release_3_0_0_rc0.tar.gz ?
I'm afraid I'm getting a build error (from fresh): HEADER src/include/features.h HEADER src/include/missing.h HEADER src/include/tls.h CC jlibtool.c CC src/lib/dict.c CC src/lib/filters.c CC src/lib/hash.c CC src/lib/hmac.c CC src/lib/hmacsha1.c CC src/lib/isaac.c CC src/lib/log.c CC src/lib/misc.c CC src/lib/missing.c CC src/lib/md4.c CC src/lib/md5.c CC src/lib/print.c CC src/lib/radius.c CC src/lib/rbtree.c CC src/lib/sha1.c CC src/lib/snprintf.c CC src/lib/strlcat.c CC src/lib/strlcpy.c CC src/lib/token.c CC src/lib/udpfromto.c CC src/lib/valuepair.c CC src/lib/fifo.c CC src/lib/packet.c CC src/lib/event.c CC src/lib/getaddrinfo.c CC src/lib/heap.c CC src/lib/tcp.c CC src/lib/base64.c /usr/bin/ld: cannot find -lregex collect2: ld returned 1 exit status make: *** [build/lib/local/libfreeradius-radius.la] Error 1 This is my configure statement: configure \ --libdir=%{_libdir}/freeradius \ --with-system-libtool \ --with-system-libltdl \ --disable-ltdl-install \ --with-udpfromto \ --with-gnu-ld \ --with-threads \ --with-thread-pool \ --with-docdir=%{docdir} \ --with-rlm-sql_postgresql-include-dir=/usr/include/pgsql \ --with-rlm-sql-postgresql-lib-dir=%{_libdir} \ --with-rlm-sql_mysql-include-dir=/usr/include/mysql \ --with-mysql-lib-dir=%{_libdir}/mysql \ --with-unixodbc-lib-dir=%{_libdir} \ --with-rlm-dbm-lib-dir=%{_libdir} \ --with-rlm-krb5-include-dir=/usr/kerberos/include \ --with-modules="rlm_wimax" \ --without-rlm_yubikey \ --without-rlm_eap_ikev2 \ --without-rlm_eap_tnc \ --without-rlm_eap_pwd \ --without-rlm_sql_iodbc \ --without-rlm_sql_firebird \ --without-rlm_sql_db2 \ --without-rlm_sql_oracle -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
On 11.07.2013 16:44, stefan.paetow@diamond.ac.uk wrote:
Did you mean https://github.com/FreeRADIUS/freeradius- server/archive/release_3_0_0_rc0.tar.gz ?
I'm afraid I'm getting a build error (from fresh): [snip] /usr/bin/ld: cannot find -lregex collect2: ld returned 1 exit status make: *** [build/lib/local/libfreeradius-radius.la] Error 1
Got exactly the same right now on a system which was running fine till now. Olivier -- Olivier Beytrison Network & Security Engineer, HES-SO Fribourg Mail: olivier@heliosnet.org
On 11 Jul 2013, at 16:01, Olivier Beytrison <olivier@heliosnet.org> wrote:
On 11.07.2013 16:44, stefan.paetow@diamond.ac.uk wrote:
Did you mean https://github.com/FreeRADIUS/freeradius- server/archive/release_3_0_0_rc0.tar.gz ?
I'm afraid I'm getting a build error (from fresh): [snip] /usr/bin/ld: cannot find -lregex collect2: ld returned 1 exit status make: *** [build/lib/local/libfreeradius-radius.la] Error 1
Got exactly the same right now on a system which was running fine till now.
*sigh* It's required for mingw, i'm surprised it wasn't picked up by the build system. I've pushed a fix and updated the tag. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Hi Arran, thanks, that's built now. All, CentOS-compatible RPMS, SRPM and .tar.bz2 are at: https://www.dropbox.com/sh/sbqyy7gvzrd3egt/rCKE7aMnku/FreeRADIUS Regards Stefan
-----Original Message----- From: freeradius-users- bounces+stefan.paetow=diamond.ac.uk@lists.freeradius.org [mailto:freeradius-users- bounces+stefan.paetow=diamond.ac.uk@lists.freeradius.org] On Behalf Of Arran Cudbard-Bell Sent: 11 July 2013 16:12 To: FreeRadius users mailing list Subject: Re: [ANN] Version 3.0.0-rc0
On 11 Jul 2013, at 16:01, Olivier Beytrison <olivier@heliosnet.org> wrote:
On 11.07.2013 16:44, stefan.paetow@diamond.ac.uk wrote:
Did you mean https://github.com/FreeRADIUS/freeradius- server/archive/release_3_0_0_rc0.tar.gz ?
I'm afraid I'm getting a build error (from fresh): [snip] /usr/bin/ld: cannot find -lregex collect2: ld returned 1 exit status make: *** [build/lib/local/libfreeradius-radius.la] Error 1
Got exactly the same right now on a system which was running fine till now.
*sigh*
It's required for mingw, i'm surprised it wasn't picked up by the build system.
I've pushed a fix and updated the tag.
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
On 11 July 2013, at 06:09, Fajar A. Nugraha <list@fajar.net> wrote:
On Thu, Jul 11, 2013 at 7:28 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote: We are now in feature freeze for 3.0. The configuration format and behaviour for 3.0 will be stable between now and the final release.
If you are planning on deploying 3.0 and have an existing 2.x.x configuration you were planning to migrate when the 3.0 is released, now would be a good time to try that, and to report any issues or problematic behaviour changes you notice.
I was not able to find a list of the changes between 2 and 3. I have possibly read somewhere that user modules which can be compiled separately from the base system in version 2, now must be compiled within version 3. I wanted to check on this.
On 11 Jul 2013, at 22:39, Doug Hardie <bc979@lafn.org> wrote:
On 11 July 2013, at 06:09, Fajar A. Nugraha <list@fajar.net> wrote:
On Thu, Jul 11, 2013 at 7:28 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote: We are now in feature freeze for 3.0. The configuration format and behaviour for 3.0 will be stable between now and the final release.
If you are planning on deploying 3.0 and have an existing 2.x.x configuration you were planning to migrate when the 3.0 is released, now would be a good time to try that, and to report any issues or problematic behaviour changes you notice.
I was not able to find a list of the changes between 2 and 3.
https://github.com/FreeRADIUS/freeradius-server/blob/master/doc/ChangeLog Or https://lists.freeradius.org/pipermail/freeradius-devel/2012-September/00698... https://lists.freeradius.org/pipermail/freeradius-users/2013-June/066846.htm...
I have possibly read somewhere that user modules which can be compiled separately from the base system in version 2, now must be compiled within version 3. I wanted to check on this.
Bundled modules no longer have their own standalone make files if that's what you're referring to. But you're fine building your own modules outside of FreeRADIUS. If you want to use the FreeRADIUS build framework, i.e. boilermake, then there's no support for specifying arbitrary paths to modules, so yes it'd have to be located within src/modules/. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 11 July 2013, at 15:24, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 11 Jul 2013, at 22:39, Doug Hardie <bc979@lafn.org> wrote:
On 11 July 2013, at 06:09, Fajar A. Nugraha <list@fajar.net> wrote:
On Thu, Jul 11, 2013 at 7:28 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote: We are now in feature freeze for 3.0. The configuration format and behaviour for 3.0 will be stable between now and the final release.
If you are planning on deploying 3.0 and have an existing 2.x.x configuration you were planning to migrate when the 3.0 is released, now would be a good time to try that, and to report any issues or problematic behaviour changes you notice.
I was not able to find a list of the changes between 2 and 3.
https://github.com/FreeRADIUS/freeradius-server/blob/master/doc/ChangeLog
Or
https://lists.freeradius.org/pipermail/freeradius-devel/2012-September/00698... https://lists.freeradius.org/pipermail/freeradius-users/2013-June/066846.htm...
I have possibly read somewhere that user modules which can be compiled separately from the base system in version 2, now must be compiled within version 3. I wanted to check on this.
Bundled modules no longer have their own standalone make files if that's what you're referring to. But you're fine building your own modules outside of FreeRADIUS.
Yes I build outside of FreeRadius so thanks for the information and the pointer to the complete list.
If you want to use the FreeRADIUS build framework, i.e. boilermake, then there's no support for specifying arbitrary paths to modules, so yes it'd have to be located within src/modules/.
-Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
If you are planning on deploying 3.0 and have an existing 2.x.x configuration you were planning to migrate when the 3.0 is released, now would be a good time to try that, and to report any issues or problematic behaviour changes you notice.
Here's one thing during make install that used to work, but now ceased. In 2.x.x, there was an easy mechanism to prevent "make install" from generously copying config files into the target config directory. This worked by doing a "mv raddb raddb-somestring". make install would not find the raddb directory and ignore it during install. That was quite cool; I have a config dir which only contains files which are actually in use; like I don't have a "users" file. If raddb is in place during a make install, this would copy the default config files (a.k.a. "random junk") into my production config. Now, with 3.0.0 if I try the same trick, I get: # mv raddb raddb-noinst # make install scripts/boiler.mk:552: raddb/all.mk: No such file or directory make: *** No rule to make target `raddb/all.mk'. Stop. I understand that the urgency of preserving existing config dirs is lower; due to the server not creating new modules in modules/ any more; these days, it can mess with mods-available as it likes. But still, the hygiene I could apply to my config previously was nice. Any chance to get this back? Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Stefan Winter wrote:
Now, with 3.0.0 if I try the same trick, I get:
# mv raddb raddb-noinst # make install scripts/boiler.mk:552: raddb/all.mk: No such file or directory make: *** No rule to make target `raddb/all.mk'. Stop.
I understand that the urgency of preserving existing config dirs is lower; due to the server not creating new modules in modules/ any more; these days, it can mess with mods-available as it likes.
But still, the hygiene I could apply to my config previously was nice.
Any chance to get this back?
It's not simple. You can do: # mv raddb raddb-noinst # mkdir raddb # touch raddb/all.mk # make install Two more commands, and it will still work. Alan DeKok.
Hi, On 15.07.2013 10:24, Alan DeKok wrote:
# mv raddb raddb-noinst # mkdir raddb # touch raddb/all.mk # make install
that's easy enough, thanks! Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Hi,
# mv raddb raddb-noinst # mkdir raddb # touch raddb/all.mk # make install
that's easy enough, thanks!
Except that it doesn't suffice :-/ INSTALL rlm_utf8.la INSTALL rlm_always.la INSTALL rlm_logintime.la INSTALL rlm_attr_filter.la INSTALL rlm_soh.la make: *** No rule to make target `/usr/local/freeradius/config/raddb/mods-config', needed by `/usr/local/freeradius/config/raddb/mods-config/perl'. Stop. Do I need to mkdir and touch all subdirs as well? Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Hi,
If you are planning on deploying 3.0 and have an existing 2.x.x configuration you were planning to migrate when the 3.0 is released, now would be a good time to try that, and to report any issues or problematic behaviour changes you notice.
The errors for people upgrading from 2.x are a bit cryptic. Of course reading README.rst will solve it, but the initial complaints when just starting with -X are: (I have user,group, and allow_core_dumps both on the top-level AND in the security subsection to have a config for 2.x and 3.x - this used to be okay, with the top-level entries simply ignored) main { security { user = "radiusd" group = "radiusd" allow_core_dumps = no } /usr/local/freeradius/config/raddb/radiusd.conf[0]: Configuration item "user" is deprecated /usr/local/freeradius/config/raddb/radiusd.conf[0]: Replace "user" with "group" } Here it complained about the top-level "user" - but suggesting to replace it with "group"? Afer commenting out the user and group ones, I got to allow_core_dumps: main { security { user = "radiusd" group = "radiusd" allow_core_dumps = no } /usr/local/freeradius/config/raddb/radiusd.conf[0]: Configuration item "allow_core_dumps" is deprecated /usr/local/freeradius/config/raddb/radiusd.conf[0]: Replace "allow_core_dumps" with "(null)" Replace with null makes it look like the config parameter doesn't exist any more; while it simply moved into security { }. Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
On 15 Jul 2013, at 09:30, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
If you are planning on deploying 3.0 and have an existing 2.x.x configuration you were planning to migrate when the 3.0 is released, now would be a good time to try that, and to report any issues or problematic behaviour changes you notice.
The errors for people upgrading from 2.x are a bit cryptic. Of course reading README.rst will solve it, but the initial complaints when just starting with -X are:
Ah! CONF_PARSER structs also have a data pointer, as well as the offset! Joy. I'll fix that. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 15 Jul 2013, at 10:04, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 15 Jul 2013, at 09:30, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
If you are planning on deploying 3.0 and have an existing 2.x.x configuration you were planning to migrate when the 3.0 is released, now would be a good time to try that, and to report any issues or problematic behaviour changes you notice.
The errors for people upgrading from 2.x are a bit cryptic. Of course reading README.rst will solve it, but the initial complaints when just starting with -X are:
Ah! CONF_PARSER structs also have a data pointer, as well as the offset! Joy. I'll fix that.
Ok, fix pushed. The deprecated items stuff is pretty dumb. If the current config item is deprecated, it just looks at the next in the CONFIG_PARSER struct and checks to see if the offset and now data pointers are the same, and if they are it prints our the 'Replace x with y' message. It will not, for example, tell you to move config items into new nested sections. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Hi,
If you are planning on deploying 3.0 and have an existing 2.x.x configuration you were planning to migrate when the 3.0 is released, now would be a good time to try that, and to report any issues or problematic behaviour changes you notice.
I must be missing something pretty obvious, so sorry if the below question is just noise... I'll have replace my sql_log instances with rlm_sql_null (*sniff*). So as I was in the process of re-weriting the first instance config, I stumbled over the 2.x parameter: sql_log sql-relay-acct-vpn { path = ${radacctdir}/sql-relay-common ... } Which is useful for knowing where the text file with the queries ends up. And in 3.0.0-rc0 ... there is no such thing?!? Or I just don't get it. mods-available/sql speaks of setting "null" and dialect to "mysql" - and the dialect config doesn't have file names. The only filename I see in the sql config is sqltracefile. Maybe that's it, but with that parameter description, the semantics would be a rather horrible mismatch. NB: README.rst doesn't mention the death of sql_log nor that sql (null) is its replacement. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
On 15 Jul 2013, at 10:30, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
If you are planning on deploying 3.0 and have an existing 2.x.x configuration you were planning to migrate when the 3.0 is released, now would be a good time to try that, and to report any issues or problematic behaviour changes you notice.
I must be missing something pretty obvious, so sorry if the below question is just noise...
I'll have replace my sql_log instances with rlm_sql_null (*sniff*).
So as I was in the process of re-weriting the first instance config, I stumbled over the 2.x parameter:
sql_log sql-relay-acct-vpn { path = ${radacctdir}/sql-relay-common ... }
Which is useful for knowing where the text file with the queries ends up.
And in 3.0.0-rc0 ... there is no such thing?!? Or I just don't get it.
mods-available/sql speaks of setting "null" and dialect to "mysql" - and the dialect config doesn't have file names.
The only filename I see in the sql config is sqltracefile. Maybe that's it, but with that parameter description, the semantics would be a rather horrible mismatch.
NB: README.rst doesn't mention the death of sql_log nor that sql (null) is its replacement.
It's logfile, which google reveals to be a valid portmanteau, despite my dislike for it. Just looking at the code, there's some slightly weird behaviour which i'm going to fix now. If no section logfile was specified it'd default to the main logfile. This would of mean that if you just wanted to log autz queries, you have to specify logfiles for acct and post-auth. The new logic just uses the logfile associated with the section. If you want to log autz queries, use logfile in the main sql instance section, if you want to log acct queries, use logfile in accounting, if you want to log post-auth queries use logfile in post-auth. If you want to use the same logfile for everything, reference it from acct and post-auth. I'll double check the default configs to make sure they list it and update the documentation. Thanks for reporting this. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 15 Jul 2013, at 11:10, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 15 Jul 2013, at 10:30, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
If you are planning on deploying 3.0 and have an existing 2.x.x configuration you were planning to migrate when the 3.0 is released, now would be a good time to try that, and to report any issues or problematic behaviour changes you notice.
I must be missing something pretty obvious, so sorry if the below question is just noise...
I'll have replace my sql_log instances with rlm_sql_null (*sniff*).
So as I was in the process of re-weriting the first instance config, I stumbled over the 2.x parameter:
sql_log sql-relay-acct-vpn { path = ${radacctdir}/sql-relay-common ... }
Which is useful for knowing where the text file with the queries ends up.
And in 3.0.0-rc0 ... there is no such thing?!? Or I just don't get it.
mods-available/sql speaks of setting "null" and dialect to "mysql" - and the dialect config doesn't have file names.
The only filename I see in the sql config is sqltracefile. Maybe that's it, but with that parameter description, the semantics would be a rather horrible mismatch.
NB: README.rst doesn't mention the death of sql_log nor that sql (null) is its replacement.
It's logfile, which google reveals to be a valid portmanteau, despite my dislike for it.
Just looking at the code, there's some slightly weird behaviour which i'm going to fix now. If no section logfile was specified it'd default to the main logfile.
This would of mean that if you just wanted to log autz queries, you have to specify logfiles for acct and post-auth.
The new logic just uses the logfile associated with the section. If you want to log autz queries, use logfile in the main sql instance section, if you want to log acct queries, use logfile in accounting, if you want to log post-auth queries use logfile in post-auth.
If you want to use the same logfile for everything, reference it from acct and post-auth.
I'll double check the default configs to make sure they list it and update the documentation.
Fixes pushed for behaviour, and to fixup the default config files. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Hi,
I'll double check the default configs to make sure they list it and update the documentation.
Fixes pushed for behaviour, and to fixup the default config files.
Good news! Just wondering: the files being written to are properly locked & thread waits for the lock - right? I have several instances of sql_log which all write to the same file, so converting them needs to keep that up. Other than those issues, I now have a server which at least starts up with my half-converted config. A couple of legacy warnings and a non-suggested directory structure, but it works! I'll now start issuing actual requests for all my vservers. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
On 15 Jul 2013, at 15:13, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
I'll double check the default configs to make sure they list it and update the documentation.
Fixes pushed for behaviour, and to fixup the default config files.
Good news!
Just wondering: the files being written to are properly locked & thread waits for the lock - right?
Yes. https://github.com/FreeRADIUS/freeradius-server/blob/master/src/modules/rlm_...
I have several instances of sql_log which all write to the same file, so converting them needs to keep that up.
That should be fine.
Other than those issues,
Or non issues :)
I now have a server which at least starts up with my half-converted config. A couple of legacy warnings and a non-suggested directory structure, but it works!
Excellent, that's good to hear. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Hi,
If you are planning on deploying 3.0 and have an existing 2.x.x configuration you were planning to migrate when the 3.0 is released, now would be a good time to try that, and to report any issues or problematic behaviour changes you notice.
Here's another thing that worked in 2.x, should continue to according to man 5 unlang, but doesn't: (0) ? if ( User-Name == "cyrus" ) (0) expand: "cyrus" -> 'cyrus' (0) ? if ( User-Name == "cyrus" ) -> FALSE (0) ? elsif ( "%{#User-Password}" == "96" ) (0) expand: "96" -> '96' (0) ERROR: %{#User-Password} (0) ERROR: ^ Unknown attribute (0) ERROR: Evaluation of condition failed for some reason. (0) else else { (0) - entering else else {...} Earlier, this would yield the number of characters in the incoming request's User-Password attribute, and see if it's exactly 96 Bytes. I don't know why the # triggers an "unknown attribute"? Looks like a bug to me... Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Stefan Winter wrote:
(0) ERROR: %{#User-Password} (0) ERROR: ^ Unknown attribute (0) ERROR: Evaluation of condition failed for some reason. (0) else else { (0) - entering else else {...}
Earlier, this would yield the number of characters in the incoming request's User-Password attribute, and see if it's exactly 96 Bytes.
I don't know why the # triggers an "unknown attribute"? Looks like a bug to me...
That code was removed because it was horrid. I've pushed a fix, including fixes to documentation. Use %{strlen:...} instead. Alan DeKok.
Hi, I'd love to try. looking at GITHUB's master branch, I see that the latest commit was 5 months ago, and the last tag is 3_0_0_beta1 ? There's also no other branch name that suggests recent versions. Anything wrong with github? Stefan On 16.07.2013 15:15, Alan DeKok wrote:
Stefan Winter wrote:
(0) ERROR: %{#User-Password} (0) ERROR: ^ Unknown attribute (0) ERROR: Evaluation of condition failed for some reason. (0) else else { (0) - entering else else {...}
Earlier, this would yield the number of characters in the incoming request's User-Password attribute, and see if it's exactly 96 Bytes.
I don't know why the # triggers an "unknown attribute"? Looks like a bug to me...
That code was removed because it was horrid.
I've pushed a fix, including fixes to documentation.
Use %{strlen:...} instead.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
On 17 Jul 2013, at 07:59, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
I'd love to try.
looking at GITHUB's master branch, I see that the latest commit was 5 months ago, and the last tag is 3_0_0_beta1 ?
You're possibly looking at Alan's repo?
Anything wrong with github?
No, we switched to hosting FreeRADIUS as an organisation on GitHub instead of it being one of Alan's personal projects. The URL for the repo changed, you may need to update your 'git remotes'. git remote show origin * remote origin Fetch URL: git@github.com:FreeRADIUS/freeradius-server.git Push URL: git@github.com:FreeRADIUS/freeradius-server.git The repo URLs should look like that. If they don't: git remote set-url origin git@github.com:FreeRADIUS/freeradius-server.git -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Hi,
Anything wrong with github?
Oh, never mind that. git.freeradius.org has a link to: http://github.com/alandekok/freeradius-server/tree/master which is probably not the best place to link to. Sure, if you read the github notice on that page it'll tell you "Alan DeKok's private copy of the FreeRADIUS Server code. Do NOT fork this. Use the link below instead. https://github.com/FreeRADIUS/freeradius-server" And if you do that, you'll get the source. But wouldn't it be much more useful to send people to the correct URL immediately? Stefan
Stefan
On 16.07.2013 15:15, Alan DeKok wrote:
Stefan Winter wrote:
(0) ERROR: %{#User-Password} (0) ERROR: ^ Unknown attribute (0) ERROR: Evaluation of condition failed for some reason. (0) else else { (0) - entering else else {...}
Earlier, this would yield the number of characters in the incoming request's User-Password attribute, and see if it's exactly 96 Bytes.
I don't know why the # triggers an "unknown attribute"? Looks like a bug to me...
That code was removed because it was horrid.
I've pushed a fix, including fixes to documentation.
Use %{strlen:...} instead.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Stefan Winter wrote:
git.freeradius.org has a link to:
Fixed. Alan DeKok.
I've been going through the packaging effort for 3.0 for Fedora/RHEL. BTW, many thanks to Stefan Paetow who did an initial spec file, Stefan's work has been a big help. I'm coming up with a list of issues as I find them, more to come later, but for now ... 1) The redhat directory is populated with the old 2.x spec file, no sense in updating this until we have a good 3.x spec file, but it should be updated prior to the official 3.0 release. 2) Man pages installed for non-existent features. rlm_policy radwatch These man pages are installed but both features are not part of 3.0 as far as I can tell. 3) Man pages missing. The following are installed in either /bin or /usr/sbin but there are no corresponding man pages. Every command installed needs to have a man page. dhcpclient radattr rad_counter rc.radiusd [1] [1] Debatable as to how necessary a man page is for rc.radiusd, it's use is subsumed by initscript documentation for SysV, plus many systems won't install it all. I only include it in the list for completeness. John
John Dennis wrote:
1) The redhat directory is populated with the old 2.x spec file, no sense in updating this until we have a good 3.x spec file, but it should be updated prior to the official 3.0 release.
OK. I've pushed a simple change which gets rid of 10 years of changelog at least.
2) Man pages installed for non-existent features.
Deleted.
3) Man pages missing.
The following are installed in either /bin or /usr/sbin but there are no corresponding man pages. Every command installed needs to have a man page.
dhcpclient radattr
Hmm... those two probably shouldn't be installed. They're really only for testing. Can the spec file just ignore them?
rad_counter rc.radiusd [1]
[1] Debatable as to how necessary a man page is for rc.radiusd, it's use is subsumed by initscript documentation for SysV, plus many systems won't install it all. I only include it in the list for completeness.
OK. Alan DeKok.
On 07/17/2013 12:26 PM, Alan DeKok wrote:
John Dennis wrote:
The following are installed in either /bin or /usr/sbin but there are no corresponding man pages. Every command installed needs to have a man page.
dhcpclient radattr
Hmm... those two probably shouldn't be installed. They're really only for testing. Can the spec file just ignore them?
Sure it's no problem for the spec file to ignore them but I'm wondering if they are valuable for testing won't others find them useful too? If so shouldn't we keep them and add a man page? Right now we don't have a "tools" subpackage, this is common for other large packages. A tools subpackage contains useful commands for admins and developers which are not necessary for running the basic package. Perhaps 3.0 is a good time to introduce a tools package and move some of this stuff into tools making it an optional install. This would also bring freeradius in line with other packages. Comments? John
On 17 Jul 2013, at 17:47, John Dennis <jdennis@redhat.com> wrote:
On 07/17/2013 12:26 PM, Alan DeKok wrote:
John Dennis wrote:
The following are installed in either /bin or /usr/sbin but there are no corresponding man pages. Every command installed needs to have a man page.
dhcpclient radattr
Hmm... those two probably shouldn't be installed. They're really only for testing. Can the spec file just ignore them?
Sure it's no problem for the spec file to ignore them but I'm wondering if they are valuable for testing won't others find them useful too? If so shouldn't we keep them and add a man page?
Right now we don't have a "tools" subpackage, this is common for other large packages. A tools subpackage contains useful commands for admins and developers which are not necessary for running the basic package. Perhaps 3.0 is a good time to introduce a tools package and move some of this stuff into tools making it an optional install. This would also bring freeradius in line with other packages. Comments?
Yes, packaging radsniff, radclient, radwho et al seems useful. What do people think about breaking the default configuration out into a separate package? It means bin/share/lib can be installed, and then a site local package used to install the configuration. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
John Dennis wrote:
Sure it's no problem for the spec file to ignore them but I'm wondering if they are valuable for testing won't others find them useful too? If so shouldn't we keep them and add a man page?
Maybe. radattr is really a test tool for RFC6929 attributes. And now for parsing %{...} expansions, and conditions in unlang. It should have no end-user utility. dhcpclient is a *very* bad DHCP client. It's meant for testing the DHCP functionality of the server. Because the other DHCP clients always want to go poke interfaces with new IP addresses.
Right now we don't have a "tools" subpackage, this is common for other large packages. A tools subpackage contains useful commands for admins and developers which are not necessary for running the basic package. Perhaps 3.0 is a good time to introduce a tools package and move some of this stuff into tools making it an optional install. This would also bring freeradius in line with other packages. Comments?
The radsniff, etc. could be put into a "tools" package. radattr and dhcpclient should probablt just be skipped during the "make install" process. I'll go see if I can do that. Alan DeKok.
Sorry John, But you do have a tools package. It's called freeradius-utils. :-) I'd guess radattr probably fits nicely into that. Stefan ________________________________________ From: freeradius-users-bounces+stefan.paetow=diamond.ac.uk@lists.freeradius.org [freeradius-users-bounces+stefan.paetow=diamond.ac.uk@lists.freeradius.org] on behalf of John Dennis [jdennis@redhat.com] Sent: Wednesday, July 17, 2013 5:47 PM To: FreeRadius users mailing list Cc: Alan DeKok Subject: Re: [ANN] Version 3.0.0-rc0 On 07/17/2013 12:26 PM, Alan DeKok wrote:
John Dennis wrote:
The following are installed in either /bin or /usr/sbin but there are no corresponding man pages. Every command installed needs to have a man page.
dhcpclient radattr
Hmm... those two probably shouldn't be installed. They're really only for testing. Can the spec file just ignore them?
Sure it's no problem for the spec file to ignore them but I'm wondering if they are valuable for testing won't others find them useful too? If so shouldn't we keep them and add a man page? Right now we don't have a "tools" subpackage, this is common for other large packages. A tools subpackage contains useful commands for admins and developers which are not necessary for running the basic package. Perhaps 3.0 is a good time to introduce a tools package and move some of this stuff into tools making it an optional install. This would also bring freeradius in line with other packages. Comments? John - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
On 17 Jul 2013, at 22:42, <stefan.paetow@diamond.ac.uk> wrote:
Sorry John,
But you do have a tools package. It's called freeradius-utils. :-)
I'd guess radattr probably fits nicely into that.
No it's part of the internal test framework. It's really of absolutely no use to anyone except developers. Really, really, were not making it up. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
autotools configure script issue/question: Why is udpfromto disabled by default? I thought udpfromto was necessary for correct operation in some configurations and benign otherwise. I thought the udpfromto option was added to 2.x because the issue was discovered in the middle of the 2.x release stream and we didnt' want to introduce potential incompatibility. If udpfromto is sometimes necessary and benign otherwise is there a reason for this to be a configuration option at all in 3.0? John -- jdennis@redhat.com
John Dennis wrote:
Why is udpfromto disabled by default?
It didn't work in some situations. But that was a while ago.
I thought udpfromto was necessary for correct operation in some configurations and benign otherwise.
I'd say "useful", not "necessary". But largely, yes.
I thought the udpfromto option was added to 2.x because the issue was discovered in the middle of the 2.x release stream and we didnt' want to introduce potential incompatibility. If udpfromto is sometimes necessary and benign otherwise is there a reason for this to be a configuration option at all in 3.0?
It should probably be enabled by default in 3.0, and the configuration option removed for 3.1. Alan DeKok.
I've built on Fedora and the unreleased RHEL-7 On RHEL-7 I built on the following architectures: ppc, s390, x86_64, ppc64, i686, s390x All of those built successfully but when I run one of our analysis tools it reports some problems, mostly in the area of multilib (multilib is where you can have more than one set of libraries on a system, e.g. 32-bit and 64-bit). The main problem is the header files have a few 32-bit vs. 64-bit items in them. Header files are not supposed to be arch specific. Normally the header files get installed in a devel package so 3rd parties can built and link new modules if they want. But the header files aren't clean, which would prohibit us from producing a devel package. One possibility is for the spec file to delete the offending elements in the header files, but it would be better if the multilib issues were not present in the FR 3.0 release at all, that would be much cleaner. Oddly there seems to be a multilib issue in one of the example python files. I have not dug into how to fix any of these yet, but I hope we can get the fixes in before 3.0 is frozen. Also there were a few other issues reported in conjunction with IPv6. I have not had time yet to go through and see if these are red herrings or not. I've attached the output of the analysis tool for review. -- John
On 19 Jul 2013, at 23:17, John Dennis <jdennis@redhat.com> wrote:
I've built on Fedora and the unreleased RHEL-7
On RHEL-7 I built on the following architectures:
ppc, s390, x86_64, ppc64, i686, s390x
All of those built successfully but when I run one of our analysis tools it reports some problems, mostly in the area of multilib (multilib is where you can have more than one set of libraries on a system, e.g. 32-bit and 64-bit). The main problem is the header files have a few 32-bit vs. 64-bit items in them. Header files are not supposed to be arch specific. Normally the header files get installed in a devel package so 3rd parties can built and link new modules if they want. But the header files aren't clean, which would prohibit us from producing a devel package. One possibility is for the spec file to delete the offending elements in the header files, but it would be better if the multilib issues were not present in the FR 3.0 release at all, that would be much cleaner.
radpaths.h is probably also a good candidate for imacroisation, meaning it won't be installed, and is not included directly. It's still good to have the information accessible somehow though. We could introduce some small wrapper functions in the server library fr_default_libdir() et al which just return the values defined in radpath.h at build time. That'd mean if you were linking against the 64bit library you'd get the 64bit libpath, and if you linked against the 32bit library you'd get the 32bit libpath. Of course if you're linking against libfreeradius-server you probably already have a pretty good idea of where the libraries are, but I guess it ensures consistency if you use the lib path value to search for the modules.
Oddly there seems to be a multilib issue in one of the example python files.
Is it attempting to compile them or something, and then complaining there are differences?
I have not dug into how to fix any of these yet, but I hope we can get the fixes in before 3.0 is frozen.
Also there were a few other issues reported in conjunction with IPv6. I have not had time yet to go through and see if these are red herrings or not.
OK.
I've attached the output of the analysis tool for review.
Thanks. -Arran
On 20 Jul 2013, at 00:21, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 19 Jul 2013, at 23:17, John Dennis <jdennis@redhat.com> wrote:
I've built on Fedora and the unreleased RHEL-7
On RHEL-7 I built on the following architectures:
ppc, s390, x86_64, ppc64, i686, s390x
All of those built successfully but when I run one of our analysis tools it reports some problems, mostly in the area of multilib (multilib is where you can have more than one set of libraries on a system, e.g. 32-bit and 64-bit). The main problem is the header files have a few 32-bit vs. 64-bit items in them. Header files are not supposed to be arch specific. Normally the header files get installed in a devel package so 3rd parties can built and link new modules if they want. But the header files aren't clean, which would prohibit us from producing a devel package. One possibility is for the spec file to delete the offending elements in the header files, but it would be better if the multilib issues were not present in the FR 3.0 release at all, that would be much cleaner.
radpaths.h is probably also a good candidate for imacroisation, meaning it won't be installed, and is not included directly.
It's still good to have the information accessible somehow though. We could introduce some small wrapper functions in the server library fr_default_libdir() et al which just return the values defined in radpath.h at build time.
That'd mean if you were linking against the 64bit library you'd get the 64bit libpath, and if you linked against the 32bit library you'd get the 32bit libpath.
Of course if you're linking against libfreeradius-server you probably already have a pretty good idea of where the libraries are, but I guess it ensures consistency if you use the lib path value to search for the modules.
Oddly there seems to be a multilib issue in one of the example python files.
Is it attempting to compile them or something, and then complaining there are differences?
I have not dug into how to fix any of these yet, but I hope we can get the fixes in before 3.0 is frozen.
Also there were a few other issues reported in conjunction with IPv6. I have not had time yet to go through and see if these are red herrings or not.
OK.
I've attached the output of the analysis tool for review.
Ok fix pushed for the headers issue. I'll look at the others later. -Arran
FYI I've packaged this for Fedora and built it for rawhide (rawhide is current development which spawns the next Fedora release). You can download the rawhide packages and/or the SRPM from the Koji build: http://koji.fedoraproject.org/koji/buildinfo?buildID=436791 You probably will not be able to simply install the rawhide packages on a current Fedora release due to dependencies/conflicts (not something I've tried). But you can always rebuild the SRPM using rpmbuild. The first Fedora release 3.0 will appear in will be F20 because we don't introduce major new versions of packages in existing releases (especially if they are not configuration compatible). FWIW the F19 train just pulled away from the station so unfortunately it's too late for F19. HTH, John -- John
Thanks, John. I'll use that SPEC as base for CentOS 6.x packages :-) Regards Stefan
-----Original Message----- From: freeradius-users- bounces+stefan.paetow=diamond.ac.uk@lists.freeradius.org [mailto:freeradius-users- bounces+stefan.paetow=diamond.ac.uk@lists.freeradius.org] On Behalf Of John Dennis Sent: 23 July 2013 00:42 To: FreeRadius users mailing list Subject: Re: [ANN] Version 3.0.0-rc0
FYI I've packaged this for Fedora and built it for rawhide (rawhide is current development which spawns the next Fedora release).
You can download the rawhide packages and/or the SRPM from the Koji build:
http://koji.fedoraproject.org/koji/buildinfo?buildID=436791
You probably will not be able to simply install the rawhide packages on a current Fedora release due to dependencies/conflicts (not something I've tried). But you can always rebuild the SRPM using rpmbuild.
The first Fedora release 3.0 will appear in will be F20 because we don't introduce major new versions of packages in existing releases (especially if they are not configuration compatible). FWIW the F19 train just pulled away from the station so unfortunately it's too late for F19.
HTH,
John
-- John - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
On 07/23/2013 05:18 AM, stefan.paetow@diamond.ac.uk wrote:
Thanks, John.
I'll use that SPEC as base for CentOS 6.x packages :-)
I'm will be making some tweaks to the spec file over the near term. For instance I just realized I make a mistake with the release field in the N-V-R, the package release increment number must precede the upstream pre-release string "rc0", I just fixed that. [1] You can track the any changes to the fedora master branch (i.e. rawhide) by cloning this git repo. git clone git://pkgs.fedoraproject.org/freeradius I'm also contemplating splitting the doc into it's own subpackage, the doc is 4.6MB, no reason to install that much data on minimal install production servers. Anyway, the point is the spec file is not frozen yet, anticipate some changes. [1] If you're interested in the details see this: https://fedoraproject.org/wiki/Packaging:NamingGuidelines?rd=Packaging/Namin... -- John
John Dennis wrote:
I'm also contemplating splitting the doc into it's own subpackage, the doc is 4.6MB, no reason to install that much data on minimal install production servers.
Yeah. Most of the docs are RFCs. There's no point in installing those on minimal servers. If you update the spec file to ignore doc/rfc*.txt, that should help. Alan DeKok.
participants (8)
-
Alan DeKok -
Arran Cudbard-Bell -
Doug Hardie -
Fajar A. Nugraha -
John Dennis -
Olivier Beytrison -
Stefan Winter -
stefan.paetow＠diamond.ac.uk