RE: [ANN] Version 3.0.0-rc0

2013-07-23 Thread stefan.paetow
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...@lists.freeradius.org
 [mailto:freeradius-users-
 bounces+stefan.paetow=diamond.ac...@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
 



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


Re: [ANN] Version 3.0.0-rc0

2013-07-23 Thread Stefan Winter
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



signature.asc
Description: OpenPGP digital signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: [ANN] Version 3.0.0-rc0

2013-07-23 Thread John Dennis
On 07/23/2013 05:18 AM, stefan.pae...@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/NamingGuidelines#Pre-Release_packages
-- 
John
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: [ANN] Version 3.0.0-rc0

2013-07-23 Thread Alan DeKok
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: [ANN] Version 3.0.0-rc0

2013-07-23 Thread John Dennis
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
$ rpmdiff-cli local-analyse scratch:6062804
Setting up before packages
Setting up after packages
[rpmdiff-cli]$ ./rpmdiff-checker --xml-output=test-work-dir/output.xml 
--nocompare test-work-dir
[BAD] [freeradius] Subpackage freeradius is not multilib-clean for x86_64 vs 
i686: 1 file has non-equal 32/64bit content:
  /etc/raddb/radiusd.conf

[INFO] [freeradius] Multilib difference for etc/raddb/radiusd.conf on x86_64 vs 
i686:
--- /etc/raddb/radiusd.conf on x86_64   2013-07-19 05:16:18.829224089 -0400
+++ /etc/raddb/radiusd.conf on i686 2013-07-19 05:18:36.53887 -0400
@@ -106,7 +106,7 @@ db_dir = ${raddbdir}
 #  make
 #  make install
 #
-libdir = /usr/lib64/freeradius
+libdir = /usr/lib/freeradius

 #  pidfile: Where to place the PID of the RADIUS server.
 #

[BAD] [freeradius-devel] Subpackage freeradius-devel is not multilib-clean for 
x86_64 vs i686: 1 file has non-equal 32/64bit content:
  /usr/include/freeradius/radpaths.h

[INFO] [freeradius-devel] Multilib difference for 
usr/include/freeradius/radpaths.h on x86_64 vs i686:
--- /usr/include/freeradius/radpaths.h on x86_642013-07-19 
05:16:36.042228062 -0400
+++ /usr/include/freeradius/radpaths.h on i686  2013-07-19 05:18:53.607225676 
-0400
@@ -1,6 +1,6 @@
 /* Automatically generated by build-radpaths-h */
 #define LOGDIR /var/log/radius
-#define LIBDIR /usr/lib64/freeradius
+#define LIBDIR /usr/lib/freeradius
 #define RADDBDIR   /etc/raddb
 #define RUNDIR /var/run
 #define SBINDIR/usr/sbin

[BAD] [freeradius-python] Subpackage freeradius-python is not multilib-clean 
for x86_64 vs i686: 2 files have non-equal 32/64bit content:
  /etc/raddb/mods-config/python/example.pyo
  /etc/raddb/mods-config/python/example.pyc

[INFO] [freeradius-python] Multilib difference for 
etc/raddb/mods-config/python/example.pyo on x86_64 vs i686:
Binary files /etc/raddb/mods-config/python/example.pyo on x86_64 and 
/etc/raddb/mods-config/python/example.pyo on i686 differ

[BAD] [freeradius] Subpackage freeradius is not multilib-clean for ppc64 vs 
ppc: 1 file has non-equal 32/64bit content:
  /etc/raddb/radiusd.conf

[INFO] [freeradius] Multilib difference for etc/raddb/radiusd.conf on ppc64 vs 
ppc:
--- /etc/raddb/radiusd.conf on ppc642013-07-19 05:17:46.229223508 -0400
+++ /etc/raddb/radiusd.conf on ppc  2013-07-19 05:15:27.709224515 -0400
@@ -106,7 +106,7 @@ db_dir = ${raddbdir}
 #  make
 #  make install
 #
-libdir = /usr/lib64/freeradius
+libdir = /usr/lib/freeradius

 #  pidfile: Where to place the PID of the RADIUS server.
 #

[BAD] [freeradius-devel] Subpackage freeradius-devel is not multilib-clean for 
ppc64 vs ppc: 1 file has non-equal 32/64bit content:
  /usr/include/freeradius/radpaths.h

[INFO] [freeradius-devel] Multilib difference for 
usr/include/freeradius/radpaths.h on ppc64 vs ppc:
--- /usr/include/freeradius/radpaths.h on ppc64 2013-07-19 05:17:46.098223868 
-0400
+++ /usr/include/freeradius/radpaths.h on ppc   2013-07-19 05:15:10.402224137 
-0400
@@ -1,6 +1,6 @@
 /* Automatically generated by build-radpaths-h */
 #define LOGDIR /var/log/radius
-#define LIBDIR /usr/lib64/freeradius
+#define LIBDIR /usr/lib/freeradius
 #define RADDBDIR   /etc/raddb
 #define RUNDIR /var/run
 #define SBINDIR/usr/sbin

[BAD] [freeradius-python] Subpackage freeradius-python is not multilib-clean 
for ppc64 vs ppc: 2 files have non-equal 32/64bit content:
  /etc/raddb/mods-config/python/example.pyo
  /etc/raddb/mods-config/python/example.pyc

[INFO] [freeradius-python] Multilib difference for 

Re: [ANN] Version 3.0.0-rc0

2013-07-22 Thread John Dennis
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


Re: [ANN] Version 3.0.0-rc0

2013-07-20 Thread Arran Cudbard-Bell

On 20 Jul 2013, at 00:21, Arran Cudbard-Bell a.cudba...@freeradius.org wrote:

 
 On 19 Jul 2013, at 23:17, John Dennis jden...@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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: [ANN] Version 3.0.0-rc0

2013-07-20 Thread Alan DeKok
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: [ANN] Version 3.0.0-rc0

2013-07-19 Thread Arran Cudbard-Bell

On 19 Jul 2013, at 23:17, John Dennis jden...@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

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


Re: [ANN] Version 3.0.0-rc0

2013-07-18 Thread John Dennis
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

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


Re: [ANN] Version 3.0.0-rc0

2013-07-17 Thread Stefan Winter
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



signature.asc
Description: OpenPGP digital signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: [ANN] Version 3.0.0-rc0

2013-07-17 Thread Arran Cudbard-Bell

On 17 Jul 2013, at 07:59, Stefan Winter stefan.win...@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: g...@github.com:FreeRADIUS/freeradius-server.git
  Push  URL: g...@github.com:FreeRADIUS/freeradius-server.git

The repo URLs should look like that. If they don't:

git remote set-url origin g...@github.com:FreeRADIUS/freeradius-server.git

-Arran

Arran Cudbard-Bell a.cudba...@freeradius.org
FreeRADIUS Development Team

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


Re: [ANN] Version 3.0.0-rc0

2013-07-17 Thread Stefan Winter
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



signature.asc
Description: OpenPGP digital signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: [ANN] Version 3.0.0-rc0

2013-07-17 Thread Alan DeKok
Stefan Winter wrote:
 git.freeradius.org has a link to:
 
 http://github.com/alandekok/freeradius-server/tree/master

  Fixed.

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


Re: [ANN] Version 3.0.0-rc0

2013-07-17 Thread John Dennis
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




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


Re: [ANN] Version 3.0.0-rc0

2013-07-17 Thread Alan DeKok
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: [ANN] Version 3.0.0-rc0

2013-07-17 Thread John Dennis
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


Re: [ANN] Version 3.0.0-rc0

2013-07-17 Thread Arran Cudbard-Bell

On 17 Jul 2013, at 17:47, John Dennis jden...@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.cudba...@freeradius.org
FreeRADIUS Development Team

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


Re: [ANN] Version 3.0.0-rc0

2013-07-17 Thread Alan DeKok
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: [ANN] Version 3.0.0-rc0

2013-07-17 Thread Alan Buxey
Hi

Don't you have freeradius-utils already. .. which contains radtest etc which is 
very useful for admins

alan

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

Re: [ANN] Version 3.0.0-rc0

2013-07-17 Thread John Dennis
On 07/17/2013 04:16 PM, Alan Buxey wrote:
 Hi
 
 Don't you have freeradius-utils already. .. which contains radtest etc
 which is very useful for admins

Yes, my bad, sorry, not enough coffee.

John
--
jden...@redhat.com
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


RE: [ANN] Version 3.0.0-rc0

2013-07-17 Thread stefan.paetow
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...@lists.freeradius.org 
[freeradius-users-bounces+stefan.paetow=diamond.ac...@lists.freeradius.org] on 
behalf of John Dennis [jden...@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
 



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


Re: [ANN] Version 3.0.0-rc0

2013-07-17 Thread Arran Cudbard-Bell

On 17 Jul 2013, at 22:42, stefan.pae...@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.cudba...@freeradius.org
FreeRADIUS Development Team

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


Re: [ANN] Version 3.0.0-rc0

2013-07-16 Thread Stefan Winter
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



signature.asc
Description: OpenPGP digital signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: [ANN] Version 3.0.0-rc0

2013-07-16 Thread Alan DeKok
Stefan Winter wrote:
 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...

  I'll take a look.

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


Re: [ANN] Version 3.0.0-rc0

2013-07-16 Thread Alan DeKok
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


Re: [ANN] Version 3.0.0-rc0

2013-07-15 Thread Stefan Winter
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



signature.asc
Description: OpenPGP digital signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: [ANN] Version 3.0.0-rc0

2013-07-15 Thread Alan DeKok
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: [ANN] Version 3.0.0-rc0

2013-07-15 Thread Stefan Winter
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



signature.asc
Description: OpenPGP digital signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: [ANN] Version 3.0.0-rc0

2013-07-15 Thread Stefan Winter
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



signature.asc
Description: OpenPGP digital signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: [ANN] Version 3.0.0-rc0

2013-07-15 Thread Arran Cudbard-Bell

On 15 Jul 2013, at 09:30, Stefan Winter stefan.win...@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.cudba...@freeradius.org
FreeRADIUS Development Team

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


Re: [ANN] Version 3.0.0-rc0

2013-07-15 Thread Arran Cudbard-Bell

On 15 Jul 2013, at 10:04, Arran Cudbard-Bell a.cudba...@freeradius.org wrote:

 
 On 15 Jul 2013, at 09:30, Stefan Winter stefan.win...@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.cudba...@freeradius.org
FreeRADIUS Development Team

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


Re: [ANN] Version 3.0.0-rc0

2013-07-15 Thread Stefan Winter
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



signature.asc
Description: OpenPGP digital signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: [ANN] Version 3.0.0-rc0

2013-07-15 Thread Arran Cudbard-Bell

On 15 Jul 2013, at 10:30, Stefan Winter stefan.win...@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.cudba...@freeradius.org
FreeRADIUS Development Team

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


Re: [ANN] Version 3.0.0-rc0

2013-07-15 Thread Arran Cudbard-Bell

On 15 Jul 2013, at 11:10, Arran Cudbard-Bell a.cudba...@freeradius.org wrote:

 
 On 15 Jul 2013, at 10:30, Stefan Winter stefan.win...@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.cudba...@freeradius.org
FreeRADIUS Development Team

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


Re: [ANN] Version 3.0.0-rc0

2013-07-15 Thread Stefan Winter
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



signature.asc
Description: OpenPGP digital signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: [ANN] Version 3.0.0-rc0

2013-07-15 Thread Arran Cudbard-Bell

On 15 Jul 2013, at 15:13, Stefan Winter stefan.win...@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_sql/sql.c#L473

 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.cudba...@freeradius.org
FreeRADIUS Development Team

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


Re: [ANN] Version 3.0.0-rc0

2013-07-12 Thread Doug Hardie

On 11 July 2013, at 15:24, Arran Cudbard-Bell a.cudba...@freeradius.org wrote:

 
 On 11 Jul 2013, at 22:39, Doug Hardie bc...@lafn.org wrote:
 
 
 On 11 July 2013, at 06:09, Fajar A. Nugraha l...@fajar.net wrote:
 
 On Thu, Jul 11, 2013 at 7:28 PM, Arran Cudbard-Bell 
 a.cudba...@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/006985.html
 https://lists.freeradius.org/pipermail/freeradius-users/2013-June/066846.html
 
 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.cudba...@freeradius.org
 FreeRADIUS Development Team
 
 -
 List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
 

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


[ANN] Version 3.0.0-rc0

2013-07-11 Thread Arran Cudbard-Bell
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.tar.gz

Arran Cudbard-Bell a.cudba...@freeradius.org
FreeRADIUS Development Team

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


Re: [ANN] Version 3.0.0-rc0

2013-07-11 Thread Fajar A. Nugraha
On Thu, Jul 11, 2013 at 7:28 PM, Arran Cudbard-Bell 
a.cudba...@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.tar.gz


Did you mean
https://github.com/FreeRADIUS/freeradius-server/archive/release_3_0_0_rc0.tar.gz?

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

Re: [ANN] Version 3.0.0-rc0

2013-07-11 Thread Arran Cudbard-Bell

On 11 Jul 2013, at 14:09, Fajar A. Nugraha l...@fajar.net wrote:

 On Thu, Jul 11, 2013 at 7:28 PM, Arran Cudbard-Bell 
 a.cudba...@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.tar.gz
 
 
 Did you mean 
 https://github.com/FreeRADIUS/freeradius-server/archive/release_3_0_0_rc0.tar.gz
  ?

Yes.

Arran Cudbard-Bell a.cudba...@freeradius.org
FreeRADIUS Development Team

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


RE: [ANN] Version 3.0.0-rc0

2013-07-11 Thread stefan.paetow
  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
 



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


Re: [ANN] Version 3.0.0-rc0

2013-07-11 Thread Olivier Beytrison
On 11.07.2013 16:44, stefan.pae...@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: oliv...@heliosnet.org
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: [ANN] Version 3.0.0-rc0

2013-07-11 Thread Arran Cudbard-Bell

On 11 Jul 2013, at 16:01, Olivier Beytrison oliv...@heliosnet.org wrote:

 On 11.07.2013 16:44, stefan.pae...@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.cudba...@freeradius.org
FreeRADIUS Development Team

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


RE: [ANN] Version 3.0.0-rc0

2013-07-11 Thread stefan.paetow
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...@lists.freeradius.org
 [mailto:freeradius-users-
 bounces+stefan.paetow=diamond.ac...@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 oliv...@heliosnet.org
 wrote:
 
  On 11.07.2013 16:44, stefan.pae...@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.cudba...@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
 



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


Re: [ANN] Version 3.0.0-rc0

2013-07-11 Thread Doug Hardie

On 11 July 2013, at 06:09, Fajar A. Nugraha l...@fajar.net wrote:

 On Thu, Jul 11, 2013 at 7:28 PM, Arran Cudbard-Bell 
 a.cudba...@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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: [ANN] Version 3.0.0-rc0

2013-07-11 Thread Arran Cudbard-Bell

On 11 Jul 2013, at 22:39, Doug Hardie bc...@lafn.org wrote:

 
 On 11 July 2013, at 06:09, Fajar A. Nugraha l...@fajar.net wrote:
 
 On Thu, Jul 11, 2013 at 7:28 PM, Arran Cudbard-Bell 
 a.cudba...@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/006985.html
https://lists.freeradius.org/pipermail/freeradius-users/2013-June/066846.html

  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.cudba...@freeradius.org
FreeRADIUS Development Team

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