Issue with building FR 3.0.x packages on Ubuntu 14.04
This has been with me for a while. When ever I try building packages I end up with *dh_installdirs install -d debian/freeradi* *us/var/tmp/freera**dius-server-3.0**.x-290316/debia**n/freeradius.di**rs: 1: /var/tmp/freera**dius-server-3.0**.x-290316/debia**n/freeradius.di**rs: usr/lib/freerad* *ius: not found/var/tmp/freera**dius-server-3.0**.x-290316/debia* *n/freeradius.di**rs: 2: /var/tmp/freera**dius-server-3.0**.x-290316/debia* *n/freeradius.di**rs: var/log/freerad* *ius: not founddh_installdirs: problem reading debian/freeradi* *us.dirs:make: * [install-arch] Error 127dpkg-buildpacka**ge: error: fakeroot debian/rules binary gave error exit status 2* Eventually gave up and went to talk to helpful linux systems person upstairs. Here's what he said ..... The only changes I made were to remove execute permission from a lot of the files in debian/, which seems to affect how the dh suite treats the files. That's probably dependent on the version of the build utilities, but they shouldn't have random execute permissions on things, really. *chmod -x debian/*.{docs,**examples,instal**l,lintian-overr* *ides,manpages,p**ostinst,postrm,**preinst,prerm}* *chmod -x debian/README.** Those are the changes after unpacking; then I literally did *fakeroot dpkg-buildpacka**ge -b -us -uc* ..... then another message saying ... ..and here's the change to the build tools which made this all break! https://anonscm.debian.org/git/debhelper/debhelper.git/commit/?h=9.20120115&... If the FR folk want to fix this, they should either (a) fix the file permissions under debian/ as mentioned above, or they should change debian/compat to "8" instead of "9"..... I've just changed debian/compat to "8" and ....... package files built successfully on Ubuntu 14.04 AND on my Raspberry Pi 3 running Ubuntu MATE
On Mar 29, 2016, at 9:42 AM, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
This has been with me for a while. When ever I try building packages I end up with
Is there any reason your message has tons of "**" inserted? That makes it difficult to read.
*dh_installdirs install -d debian/freeradi* *us/var/tmp/freera**dius-server-3.0**.x-290316/debia**n/freeradius.di**rs: 1: /var/tmp/freera**dius-server-3.0**.x-290316/debia**n/freeradius.di**rs: usr/lib/freerad* *ius: not found/var/tmp/freera**dius-server-3.0**.x-290316/debia* *n/freeradius.di**rs: 2: /var/tmp/freera**dius-server-3.0**.x-290316/debia* *n/freeradius.di**rs: var/log/freerad* *ius: not founddh_installdirs: problem reading debian/freeradi*
That's... confusing.
The only changes I made were to remove execute permission from a lot of the files in debian/, which seems to affect how the dh suite treats the files.
Uh... why? I'm sure they think they have good reasons, but it's... weird.
..and here's the change to the build tools which made this all break! https://anonscm.debian.org/git/debhelper/debhelper.git/commit/?h=9.20120115&...
<sigh> And no oversight or attempts at backwards compatibility.
If the FR folk want to fix this, they should either (a) fix the file permissions under debian/ as mentioned above, or they should change debian/compat to "8" instead of "9".....
I've made the files non-executable. Alan DeKok.
Is there any reason your message has tons of "**" inserted? That makes it difficult to read.
AlI I did was copy and paste what appeared on the console during the attempted package build. Rgds A On 29 March 2016 at 14:56, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 29, 2016, at 9:42 AM, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
This has been with me for a while. When ever I try building packages I
end
up with
Is there any reason your message has tons of "**" inserted? That makes it difficult to read.
*dh_installdirs install -d debian/freeradi*
*us/var/tmp/freera**dius-server-3.0**.x-290316/debia**n/freeradius.di**rs:
1: /var/tmp/freera**dius-server-3.0**.x-290316/debia**n/freeradius.di**rs: usr/lib/freerad* *ius: not found/var/tmp/freera**dius-server-3.0**.x-290316/debia* *n/freeradius.di**rs: 2: /var/tmp/freera**dius-server-3.0**.x-290316/debia* *n/freeradius.di**rs: var/log/freerad* *ius: not founddh_installdirs: problem reading debian/freeradi*
That's... confusing.
The only changes I made were to remove execute permission from a lot of the files in debian/, which seems to affect how the dh suite treats the files.
Uh... why? I'm sure they think they have good reasons, but it's... weird.
..and here's the change to the build tools which made this all break!
https://anonscm.debian.org/git/debhelper/debhelper.git/commit/?h=9.20120115&...
<sigh> And no oversight or attempts at backwards compatibility.
If the FR folk want to fix this, they should either (a) fix the file permissions under debian/ as mentioned above, or they should change debian/compat to "8" instead of "9".....
I've made the files non-executable.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hello Everyone, I'm using FreeRadius 2.2-9, Mikrotik as NAS and MySQL InnodB Database. All is working fine, including Interim-Updates from my NAS's to Radius. Is there a way to did a "reverse" action? Interim-Update from Radius to NAS? I ask because when I lost stop packets, the client IP is blocked forever!!! Someone can help me? If don't have a way to do this, what's the best way to solve? Post-Auth exec or Database Stored Procedure? Aurélio
On 3/29/2016 12:55 PM, Aurélio de Souza Ribeiro Neto wrote:
Hello Everyone,
I'm using FreeRadius 2.2-9, Mikrotik as NAS and MySQL InnodB Database.
All is working fine, including Interim-Updates from my NAS's to Radius.
Is there a way to did a "reverse" action? Interim-Update from Radius to NAS?
No. This is completely non nonsensical to the way radius functions.
I ask because when I lost stop packets, the client IP is blocked forever!!!
Lost (not received) accounting packets will not have any affect on your customer's connection. Bill
Someone can help me?
If don't have a way to do this, what's the best way to solve? Post-Auth exec or Database Stored Procedure?
Aurélio
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
You not going to be able to rely on the accounting packet stop receipt to release the ip. There's a SNMP script that you can use (i forget the name) to pol the nas for connections. If not found then you manually release the ip in the table. Someone here will know the details. Bill On 3/29/2016 1:48 PM, Aurélio de Souza Ribeiro Neto wrote:
Thanks Bill,
Lost (not received) accounting packets will not have any affect on your customer's connection.
For my customer's no affect but for my dhcp_pool I lost an IP.
Aurélio
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Tue, Mar 29, 2016 at 09:56:20AM -0400, Alan DeKok wrote:
On Mar 29, 2016, at 9:42 AM, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
*dh_installdirs install -d debian/freeradi* *us/var/tmp/freera**dius-server-3.0**.x-290316/debia**n/freeradius.di**rs: 1: /var/tmp/freera**dius-server-3.0**.x-290316/debia**n/freeradius.di**rs: usr/lib/freerad* *ius: not found/var/tmp/freera**dius-server-3.0**.x-290316/debia* *n/freeradius.di**rs: 2: /var/tmp/freera**dius-server-3.0**.x-290316/debia* *n/freeradius.di**rs: var/log/freerad* *ius: not founddh_installdirs: problem reading debian/freeradi*
That's... confusing.
I guess that's a symptom of the new "feature" where executable files are run rather than included directly. And those files aren't intended to be executed.
The only changes I made were to remove execute permission from a lot of the files in debian/, which seems to affect how the dh suite treats the files.
Uh... why? I'm sure they think they have good reasons, but it's... weird.
Guess it's more flexible, but seems a bit of a weird way to do it. I generally find that requiring file permissions to always be correct having been in a VCS or some sort of archive or similar can often have problems.
..and here's the change to the build tools which made this all break! https://anonscm.debian.org/git/debhelper/debhelper.git/commit/?h=9.20120115&...
<sigh> And no oversight or attempts at backwards compatibility.
freeradius-server/debian/compat contains "9", which is where this "feature" started. It should in theory not break if that file contains a smaller number. That was bumped up from 7 to 9 in FR commit 5dbe5dd1e18eda in September. But the weird thing is I've been building debian packages for Debian wheezy and jessie, on wheezy and jessie, since then and had no problems at all. Jessie's debhelper is version 9 and has the linked patch. Maybe something else is different on Ubuntu. Not worth worrying about now the modes are sorted. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
participants (5)
-
Alan DeKok -
Alex Sharaz -
Aurélio de Souza Ribeiro Neto -
Bill Schoolfield -
Matthew Newton