Wiki build instructions
I've cleaned up the wiki pages for build/package instructions. If anyone would like to contribute, we're currently missing: - Instructions for building RHEL/Centos packages (http://wiki.freeradius.org/building/RHEL-and-Centos) - Instructions for installing GCC 4.9 on OpenSuse (http://wiki.freeradius.org/building/Suse%20and%20OpenSuse) - Instructions for satisfying dependencies on OpenSuse (http://wiki.freeradius.org/building/Suse%20and%20OpenSuse) - Complete instructions for building packages on OpenSuse (http://wiki.freeradius.org/building/Suse%20and%20OpenSuse) Please use http://wiki.freeradius.org/building/Debian%20and%20Ubuntu as a template. It'd also be good to check that the instructions actually worked :) -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
One thing I have noticed is when building the RPMs on RHEL 7 is the way you now need to use systemctl. Oh how I miss the init.d script simplicity. The radiusd.service gets dropped into /usr/lib/systemd/system/radiusd.service and in there it references /etc/sysconfig/radiusd for any custom settings on startup as per how the RPM is built using the RPM spec file. Any thoughts about also creating a /etc/sysconfig/radiusd file with a commented out example as part of the default deployment and naturally don't update it when upgrading the RPMs. #Radius config, load the configuration from a different directory #FREERADIUS_OPTIONS="-d /appl/freeradius/Internal/raddb" I couldn't see any other variables used apart from FREERADIUS_OPTIONS as systemctl is just calling radiusd with command line options. On Wed, Oct 19, 2016 at 10:08 AM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
I've cleaned up the wiki pages for build/package instructions.
If anyone would like to contribute, we're currently missing:
- Instructions for building RHEL/Centos packages ( http://wiki.freeradius.org/building/RHEL-and-Centos)
- Instructions for installing GCC 4.9 on OpenSuse ( http://wiki.freeradius.org/building/Suse%20and%20OpenSuse) - Instructions for satisfying dependencies on OpenSuse ( http://wiki.freeradius.org/building/Suse%20and%20OpenSuse) - Complete instructions for building packages on OpenSuse ( http://wiki.freeradius.org/building/Suse%20and%20OpenSuse)
Please use http://wiki.freeradius.org/building/Debian%20and%20Ubuntu as a template.
It'd also be good to check that the instructions actually worked :)
-Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Tue, Oct 18, 2016 at 05:08:54PM -0400, Arran Cudbard-Bell wrote:
I've cleaned up the wiki pages for build/package instructions.
Nice. The "Getting the source" is good for Debian, but not so much for other distributions - the cherry pick for v3.0.12 is only required for the debian packaging (so not a problem on other systems), but it also says get v3.0.11.zip, which is because the v3.0.12.zip dosn't work on Debian (due to the cherry-pick). But I like the idea of pulling in that page onto all the other pages. Makes much more sense :)
It'd also be good to check that the instructions actually worked :)
Yeah... it would have been better if I'd actually tested building Debian packages in the days (rather than a few weeks) before 3.0.12 was released :( grrr. Can some of the instructions should be changed around slightly? I think the priority should be to get 3.0.x built as easily as possible. So unnecessary things such as the scary "upgrade GCC" on Debian or "how to get libkqueue even though Suse hasn't got it" don't need to be highlighted at the top of the page, but more in a "for developers building 3.1.x/4.0.x" part lower down? Just don't want to scare people off with instructions they don't need. Maybe just split each page into Building the latest stable version and Building development versions would solve that. The "getting the source" is different as well anyway. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.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>
On Oct 19, 2016, at 5:43 AM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Tue, Oct 18, 2016 at 05:08:54PM -0400, Arran Cudbard-Bell wrote:
I've cleaned up the wiki pages for build/package instructions.
Nice.
The "Getting the source" is good for Debian, but not so much for other distributions - the cherry pick for v3.0.12 is only required for the debian packaging (so not a problem on other systems), but it also says get v3.0.11.zip, which is because the v3.0.12.zip dosn't work on Debian (due to the cherry-pick).
But I like the idea of pulling in that page onto all the other pages. Makes much more sense :)
Yes, I know it's only technically required for debian, but it doesn't do any harm for the others :)
It'd also be good to check that the instructions actually worked :)
Yeah... it would have been better if I'd actually tested building Debian packages in the days (rather than a few weeks) before 3.0.12 was released :( grrr.
Can some of the instructions should be changed around slightly? I think the priority should be to get 3.0.x built as easily as possible. So unnecessary things such as the scary "upgrade GCC" on Debian or "how to get libkqueue even though Suse hasn't got it" don't need to be highlighted at the top of the page, but more in a "for developers building 3.1.x/4.0.x" part lower down?
Just don't want to scare people off with instructions they don't need.
I've added notes about the steps not being required for certain versions. The wiki pages get updated infrequently, so i'm trying to write documentation that won't automatically get outdated. -Arran
On Wed, Oct 19, 2016 at 09:06:34AM -0400, Alan DeKok wrote:
On Oct 19, 2016, at 5:43 AM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
Maybe just split each page into
Building the latest stable version
and
Building development versions
Sounds good to me.
OK, just done that. Can anyone do a quick read and see if it's clearer? On Wed, Oct 19, 2016 at 05:18:41PM -0400, Arran Cudbard-Bell wrote:
The wiki pages get updated infrequently, so i'm trying to write documentation that won't automatically get outdated.
Yeah :( But there have been too many questions recently with problems that would have not occurred if people had followed the build instructions. Which seems to me to indicate the instructions still aren't simple enough <sadface>. If that comes at the expense of updating a few wiki pages every now and then, it's worth it to save questions here. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.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 (4)
-
Alan DeKok -
Arran Cudbard-Bell -
Matthew Newton -
Peter Lambrechtsen