hi I'm starting with linux and freeradius with peap configuration. I'm using debian lenny 2.6.26-2-686, when runnig freeradius -X (FreeRADIUS Version 2.0.4, for host i486-pc-linux-gnu, built on Sep 7 2008 at 23:35:34) i'm getting those errors Module: Instantiating eap eap { default_eap_type = "peap" timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no } Module: Linked to sub-module rlm_eap_md5 Module: Instantiating eap-md5* rlm_eap: Ignoring EAP-Type/tls because we do not have OpenSSL support. rlm_eap: Ignoring EAP-Type/peap because we do not have OpenSSL support. rlm_eap: Ignoring EAP-Type/ttls because we do not have OpenSSL support.* Module: Linked to sub-module rlm_eap_mschapv2 Module: Instantiating eap-mschapv2 mschapv2 { with_ntdomain_hack = no } *rlm_eap: No such sub-type for default EAP type peap* /etc/freeradius/eap.conf[1]: Instantiation failed for module "eap" /etc/freeradius/sites-enabled/inner-tunnel[223]: Failed to find module "eap". /etc/freeradius/sites-enabled/inner-tunnel[176]: Errors parsing authenticate section. } } *Errors initializing modules* how should i install openssl ?? only compilation by hand will work here ?? Can anybody give needed advice please? Thanks a lot for help! :) Kornel
Le mardi 04 mai 2010 à 19:51 +0200, ds14.kornel a écrit :
hi I'm starting with linux and freeradius with peap configuration. I'm using debian lenny 2.6.26-2-686, when runnig freeradius -X (FreeRADIUS Version 2.0.4, for host i486-pc-linux-gnu, built on Sep 7 2008 at 23:35:34) i'm getting those errors
Module: Instantiating eap eap { default_eap_type = "peap" timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no } Module: Linked to sub-module rlm_eap_md5 Module: Instantiating eap-md5 rlm_eap: Ignoring EAP-Type/tls because we do not have OpenSSL support. rlm_eap: Ignoring EAP-Type/peap because we do not have OpenSSL support. rlm_eap: Ignoring EAP-Type/ttls because we do not have OpenSSL support. Module: Linked to sub-module rlm_eap_mschapv2 Module: Instantiating eap-mschapv2 mschapv2 { with_ntdomain_hack = no } rlm_eap: No such sub-type for default EAP type peap /etc/freeradius/eap.conf[1]: Instantiation failed for module "eap" /etc/freeradius/sites-enabled/inner-tunnel[223]: Failed to find module "eap". /etc/freeradius/sites-enabled/inner-tunnel[176]: Errors parsing authenticate section. } } Errors initializing modules
how should i install openssl ?? only compilation by hand will work here ?? Can anybody give needed advice please?
Thanks a lot for help! :)
I would say you will have to install openssl developement headers and recompile freeradius with the corrects switches to enable eap module. sudo apt-get install libssl-dev and then recompile with --with-rlm-eap This is just a guess.
Kornel
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Alexandre Chapellon <alexandre.chapellon@mana.pf> Mana SAS
Hi,
} rlm_eap: No such sub-type for default EAP type peap /etc/freeradius/eap.conf[1]: Instantiation failed for module "eap" /etc/freeradius/sites-enabled/inner-tunnel[223]: Failed to find module "eap". /etc/freeradius/sites-enabled/inner-tunnel[176]: Errors parsing authenticate section. } } Errors initializing modules
yep - the default debian install doesnt have OpenSSL support. http://wiki.freeradius.org/Build#Building_Debian_packages alan
On Tue, May 04, 2010 at 07:58:03PM +0100, Alan Buxey wrote:
rlm_eap: No such sub-type for default EAP type peap
yep - the default debian install doesnt have OpenSSL support.
No, only the default build of 2.1.8 from original source on Debian lacks the libssl-dev build-dependency. The pre-built packages are fine, and that's what everyone, ESPECIALLY NEWBIES, should be using. Let me repeat the simple guide once again: 1.) Add Debian lenny-backports repository to your sources.list, for example: deb http://backports.org/debian lenny-backports main 2.) Update the package list, for example with: apt-get update 3.) Install the the main FreeRADIUS package from there, for example with: apt-get install -t lenny-backports freeradius -- 2. That which causes joy or happiness.
Hi,
yep - the default debian install doesnt have OpenSSL support. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
No, only the default build of 2.1.8 from original source on Debian lacks the libssl-dev build-dependency. The pre-built packages are fine, and that's
yes, thats what I said...look above.
3.) Install the the main FreeRADIUS package from there, for example with: apt-get install -t lenny-backports freeradius
alternatively, grab the source and build it yourself. the choice is yours. alan
On Tue, May 04, 2010 at 09:39:30PM +0100, Alan Buxey wrote:
3.) Install the the main FreeRADIUS package from there, for example with: apt-get install -t lenny-backports freeradius
alternatively, grab the source and build it yourself. the choice is yours.
No, I think that is a false choice for these users. We should not be telling random newbies to take a route that has time and time again been demonstrated to be too complicated for them to handle, when they can easily use a more efficient method - install safe working binaries. That also has the benefit of keeping them in the loop for later updates from the same reliable channel. If they explicitly tell us that they already use Debian, then we can't have much reason to have them avoid these Debian-specific methods that accomplish our goals - to make these people happy users of FR. This is one fairly trivial bug, even if one knows very little about compiling source code - one just has to google, and/or read the official web site (wiki), and find that all they have to do is install that one package and restart the build process, and they're good - yet numerous users have sent an e-mail to the list saying it's been a showstopper for them. I do not see what is there to gain by telling these people to keep using a method they clearly do not understand enough to be able to solve a relatively easy problem with. Sure, they can apply this quick fix now, but will it help their FreeRADIUS experience, and in turn will it help FreeRADIUS? Isn't it better for all to get them past the installation phase as quickly as possible, and not have to rehash these tangential issues, when time could be better spent educating them about core issues such as FreeRADIUS configuration semantics, or RADIUS protocol issues? -- 2. That which causes joy or happiness.
On 05/04/2010 06:21 PM, Josip Rodin wrote:
On Tue, May 04, 2010 at 09:39:30PM +0100, Alan Buxey wrote:
3.) Install the the main FreeRADIUS package from there, for example with: apt-get install -t lenny-backports freeradius
alternatively, grab the source and build it yourself. the choice is yours.
No, I think that is a false choice for these users. We should not be telling random newbies to take a route that has time and time again been demonstrated to be too complicated for them to handle, when they can easily use a more efficient method - install safe working binaries. That also has the benefit of keeping them in the loop for later updates from the same reliable channel. If they explicitly tell us that they already use Debian, then we can't have much reason to have them avoid these Debian-specific methods that accomplish our goals - to make these people happy users of FR.
This is one fairly trivial bug, even if one knows very little about compiling source code - one just has to google, and/or read the official web site (wiki), and find that all they have to do is install that one package and restart the build process, and they're good - yet numerous users have sent an e-mail to the list saying it's been a showstopper for them.
I do not see what is there to gain by telling these people to keep using a method they clearly do not understand enough to be able to solve a relatively easy problem with. Sure, they can apply this quick fix now, but will it help their FreeRADIUS experience, and in turn will it help FreeRADIUS? Isn't it better for all to get them past the installation phase as quickly as possible, and not have to rehash these tangential issues, when time could be better spent educating them about core issues such as FreeRADIUS configuration semantics, or RADIUS protocol issues?
+1 I completely agree. Building *and* installing FreeRADIUS from source requires technical skill that exceeds the technical competence of a significant proportion of the users on this list. One only needs to spend a short period here to see this is clearly the case. I have to agree with Josip that whenever possible users should be directed to install pre-built packages with the advice to build it yourself being dispensed only with great care. It would also help if we could converge on a stable release that's usable for a significant duration. Users are told to run the latest release, which may be only a few weeks or months old which makes it difficult for the distribution channels for pre-built binaries to keep up by always having the latest release available. Since it's often the case the latest release is not available in the distribution channel users are forced into building it themselves with all the bad results and frustration vented here. If we had a stable release I suspect a lot of this frustration would be mitigated. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
John Dennis wrote:
I have to agree with Josip that whenever possible users should be directed to install pre-built packages with the advice to build it yourself being dispensed only with great care.
The Wiki could be updated to make all of that clearer, too.
It would also help if we could converge on a stable release that's usable for a significant duration.
2.1.x is the "long term support" version. Using "git" is making this process much easier. 2.2.0 will be the track that adds new features, like possibly RadSec, and other interesting things.
Users are told to run the latest release, which may be only a few weeks or months old which makes it difficult for the distribution channels for pre-built binaries to keep up by always having the latest release available. Since it's often the case the latest release is not available in the distribution channel users are forced into building it themselves with all the bad results and frustration vented here. If we had a stable release I suspect a lot of this frustration would be mitigated.
Once the distributions have a stable release with OpenSSL support, the majority of the problems should go away. Alan DeKok.
On Wed, May 05, 2010 at 04:43:37PM +0200, Alan DeKok wrote:
John Dennis wrote:
I have to agree with Josip that whenever possible users should be directed to install pre-built packages with the advice to build it yourself being dispensed only with great care.
The Wiki could be updated to make all of that clearer, too.
If you gave some of us an account on the Wiki, you wouldn't have to worry about that... hint hint :) -- 2. That which causes joy or happiness.
participants (6)
-
Alan Buxey -
Alan DeKok -
Alexandre Chapellon -
ds14.kornel -
John Dennis -
Josip Rodin