Re: Installing Freeradius on Debian
If anyone else wants to use the debian packages I created from the 20030930 snapshot, you can find them here: http://www.mrtizmo.com/freeradius/ I removed these modules: rlm_dbm rlm_eap rlm_krb5 rlm_ldap rlm_mschap rlm_ns_mta_md5 rlm_x99_token Have fun! Nick -- Nick Davis Associate Systems Administrator [EMAIL PROTECTED] Internet Exposure, Inc. http://www.iexposure.com (612)676-1946 Web Development-Web Marketing-ISP Services - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Installing Freeradius on Debian
> > So one think to keep in mind when splitting out the modules: if the > > module is not being installed, do not try to use it in radius.conf. You > > will probably want to work some sed magic to (un)comment the modules in > > the auth type sections at the bottom of the radius.conf based on which > > modules are installed. > > Interesting point... I might have to go fix it so that failing to start > the server doesn't cause installation failure... To my mind server start > failure is probably not so bad 'cause I suspect an unconfigured RADIUS > server would not be a pleasant thing to have running. Actually it just occurred to me, I don't think the server should start on install. It would start a non-configured service on a potentially live system, potentially with all modules loaded. > On the other hand, the idea of the default config is to have a running > server as easily as possible, so I might indeed have to comment out those > modules (ldap, krb5) which are split out but referenced by default... I > can't do that in the main server CVS, it'll have to be a change in a > Debian-local .diff.gz. So it'll have to wait until we're actually in > Debian. If you want to be able to have a running system as easily as possible, does that imply the installation script should attempt to start the service? I think it should just configure it to be able to run, and then allow the user to start it when they are ready to. > Funnily enough, these are the first two changes after 0.71's release, > which was the last version in Debian and what I presume you used to be > running. Yes I am running a source install from around the 0.71 time frame. There haven't been any changes that effect me, so I didn't see a good reason to upgrade. Now I am setting up a new server, I figured it would be a great time to get the latest version running. Thanks! Nick -- Nick Davis Associate Systems Administrator [EMAIL PROTECTED] Internet Exposure, Inc. http://www.iexposure.com (612)676-1946 Web Development-Web Marketing-ISP Services - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Installing Freeradius on Debian
> > Is this enormous list a good enough reason to split the freeradius > > package into sub-packages? > > Nope. A massive list of _souce_ dependancies isn't a problem in any way... > > Happily, it looks like the source-dependancies on the package are correct, > too. I was going to check that in a pbuilder some time, but your result > gives me a little confidence boost. Well after making the necessary changes to the freeradius config files to work with my system, I started up freeradius and it works just fine as far as I can tell:) I ran it with -xx and used radtest to authenticate a user and it was successful. I'm going to make it my live system hopefully late tonight. The only thing I'll need to test once the system is live is the Simultaneous-Use via sql. I have Simult-Use setup to work the same as my current version, but I need to have users already logged in to know for sure if it works. Thanks for the help! Nick -- Nick Davis Associate Systems Administrator [EMAIL PROTECTED] Internet Exposure, Inc. http://www.iexposure.com (612)676-1946 Web Development-Web Marketing-ISP Services - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Installing Freeradius on Debian
> From: Nick Davis
> Sent: Wednesday, 1 October 2003 7:48 AM
> > > The freeradius I downloaded is: freeradius-snapshot-20030930
> One thing to note, when installing the deb files with dpkg -i, it will try to
> start the freeradius daemon. That failed because all of the modules that I
> removed were still defined in radius.conf.
> So one think to keep in mind when splitting out the modules: if the module is
> not being installed, do not try to use it in radius.conf. You will probably
> want to work some sed magic to (un)comment the modules in the auth type
> sections at the bottom of the radius.conf based on which modules are
> installed.
Interesting point... I might have to go fix it so that failing to start
the server doesn't cause installation failure... To my mind server start
failure is probably not so bad 'cause I suspect an unconfigured RADIUS
server would not be a pleasant thing to have running.
On the other hand, the idea of the default config is to have a running
server as easily as possible, so I might indeed have to comment out those
modules (ldap, krb5) which are split out but referenced by default... I
can't do that in the main server CVS, it'll have to be a change in a
Debian-local .diff.gz. So it'll have to wait until we're actually in Debian.
> One other thing, if there is database module that is separate from the main
> freeradius package, make sure to instruct the user to create the database and
> modify "sql.conf" for things to work. It might be obvious to you and I, but
> it will save some help questions!
I think I will leave this alone. That would be required whether the DB module
was part of the main server or a seperate package, and the examples directory
has sample .sql files. I think it's well-enough documented that we don't need
extra notifications for people...
> I noticed a new change in sql.conf. My older version has these definitions:
>
> 1.
> # simul_zap_query - query to close "stale" sessions where NAS
> shows call
> # - was disconnected, but no stop account packet
> was received.
> # - ( %s will be replaced with the appropriate
> RadAcctId )
> # - Leave blank or commented out to skip zapping
> stale sessions
> ###
>
> 2.
> simul_zap_query = "DELETE FROM ${acct_table1} WHERE RadAcctId = '%s'"
>
>
> Why are these not in the new version?
http://www.freeradius.org/cgi-bin/cvsweb.cgi/radiusd/raddb/sql.conf
sql.conf 1.21
"Remove simul_zap_query and replace it with a call to session_zap.
Fix a typo in the dialup_admin Changelog"
> I also noticed that this has been removed:
>
> ###
> # Authentication Query
>
> ###
> # This query is used only to get the password for the
> # user we want to authenticate. The password MUST
> # be the first field in the return row data.
> # The 'Password' attribute is deprecated in favor of 'User-Password'.
>
> ###
>
> authenticate_query = "SELECT passwd,Attribute FROM ${authcheck_table}
> WHERE userid = '%{User-Name}' AND ( Attribute = 'User-Password' OR Attribute
> = 'Password' OR Attribute = 'Crypt-Password' ) ORDER BY Attribute DESC"
sql.conf 1.20
"Add an sql_groupcmp and a corresponding attribute Sql-Group. Remove the
authenticate_query from rlm_sql. The authorize_query should be enough."
Funnily enough, these are the first two changes after 0.71's release,
which was the last version in Debian and what I presume you used to be
running.
> I'm guessing this was removed because you cannot put the sql module in the
> authentication section of radius.conf anymore, but I am not sure which sql
> query takes its place. My guess is the "authorize_check_query". If I am wrong
> please correct me.
That makes sense to me.
--
Paul "TBBle" Hampson
Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]
On a sidewalk near Portland State
University someone wrote `Trust Jesus', and
someone else wrote `But Cut the Cards'.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Installing Freeradius on Debian
> From: Nick Davis > Sent: Wednesday, 1 October 2003 6:02 AM > I decided to install the 47 dependencies and try to create the debian packages > on the Sarge testing system. > > The freeradius I downloaded is: freeradius-snapshot-20030930 > > When I run the command: > dpkg-buildpackage -us -uc -b -rfakeroot > > Here is the list of packages I had to install (YUCK!): > > binutils dpkg-dev make fakeroot autoconf autoconf2.13 autotools-dev comerr-dev > cpp cpp-3.3 debconf-utils debhelper gcc gcc-3.3 gettext html2text > intltool-debian libasn1-6-heimdal libc6-dev libcomerr1-kerberos4kth libecpg3 > libgdbm-dev libiodbc2 libiodbc2-dev libkadm55 libkrb-1-kerberos4kth > libkrb5-17-heimdal libkrb5-dev libkrb53 libldap2-dev libltdl3 libltdl3-dev > libmysqlclient10-dev libpam0g-dev libpq3 libroken16-kerberos4kth > libsasl2-dev libsnmp4.2 libsnmp4.2-dev libssl-dev libtool1.4 m4 po-debconf > postgresql-dev snmp zlib1g-dev > > Is this enormous list a good enough reason to split the freeradius package > into sub-packages? Nope. A massive list of _souce_ dependancies isn't a problem in any way... Happily, it looks like the source-dependancies on the package are correct, too. I was going to check that in a pbuilder some time, but your result gives me a little confidence boost. -- Paul "TBBle" Hampson Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] On a sidewalk near Portland State University someone wrote `Trust Jesus', and someone else wrote `But Cut the Cards'. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Installing Freeradius on Debian
> > The freeradius I downloaded is: freeradius-snapshot-20030930
> > My question is: how can I remove some of the build dependencies for
> > packages that I do not intent to use?
>
> libpam0g-dev is used by rlm_pam
>
> libgbmg1 is used by rlm_counter, rlm_gdbm and rlm_ippool
>
> postgresql-dev is for rlm_sql_postgresql
>
> libldap2-dev and libsasl2-dev are for rlm_ldap
>
> libiodbc2-dev is for rlm_sql_iodbc
>
> libkrb5-dev is for rlm_krb5
>
> None of these build-dependancies are for the core daemon.
>
> The way I'd do it is remove those modules from the 'stable' file in
> src/modules or src/modules/rlm_sql/ depending on which modules they are.
> This step is basically optional, since it should skip that which it can't
> build.
>
> Then remove the entries for those things from debian/rules in the various
> 'for each' clauses. And remove the entries from the debian/control file.
> (ie. the opposite of the freeradius-iodbc patch you've already got. :-)
>
> Then remove the build-dependancies that trouble you so.
>
> You'll need that libltdl3-dev, however. No way around it except building
> statically, and I dunno what that does to the build-dependancies, or the
> rlm_sql and rlm_eap modules.
I followed your above instructions for removing unwanted modules and it
created and installed the .deb files just fine.
***
One thing to note, when installing the deb files with dpkg -i, it will try to
start the freeradius daemon. That failed because all of the modules that I
removed were still defined in radius.conf.
So one think to keep in mind when splitting out the modules: if the module is
not being installed, do not try to use it in radius.conf. You will probably
want to work some sed magic to (un)comment the modules in the auth type
sections at the bottom of the radius.conf based on which modules are
installed.
One other thing, if there is database module that is separate from the main
freeradius package, make sure to instruct the user to create the database and
modify "sql.conf" for things to work. It might be obvious to you and I, but
it will save some help questions!
I noticed a new change in sql.conf. My older version has these definitions:
1.
# simul_zap_query - query to close "stale" sessions where NAS
shows call
# - was disconnected, but no stop account packet
was received.
# - ( %s will be replaced with the appropriate
RadAcctId )
# - Leave blank or commented out to skip zapping
stale sessions
###
2.
simul_zap_query = "DELETE FROM ${acct_table1} WHERE RadAcctId = '%s'"
Why are these not in the new version?
I also noticed that this has been removed:
###
# Authentication Query
###
# This query is used only to get the password for the
# user we want to authenticate. The password MUST
# be the first field in the return row data.
# The 'Password' attribute is deprecated in favor of 'User-Password'.
###
authenticate_query = "SELECT passwd,Attribute FROM ${authcheck_table}
WHERE userid = '%{User-Name}' AND ( Attribute = 'User-Password' OR Attribute
= 'Password' OR Attribute = 'Crypt-Password' ) ORDER BY Attribute DESC"
I'm guessing this was removed because you cannot put the sql module in the
authentication section of radius.conf anymore, but I am not sure which sql
query takes its place. My guess is the "authorize_check_query". If I am wrong
please correct me.
That's all for now. I'll test it more tomorrow.
Nick
--
Nick Davis
Associate Systems Administrator
[EMAIL PROTECTED]
Internet Exposure, Inc.
http://www.iexposure.com
(612)676-1946
Web Development-Web Marketing-ISP Services
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Installing Freeradius on Debian
Nick Davis <[EMAIL PROTECTED]> wrote: > When it tries to build, it quits with this problem: ... The CVS snapshot from tomorrow should contain the fix. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Installing Freeradius on Debian
> > I am building the debian package on a debian Woody stable system and am > > going to copy it over to a debian Sarge testing system. > > Wild. Any reason you're not building it on a testing system? I'd offer to > do so, but my testing machine is also PowerPC, and so the packages probably > aren't a lot of use to you. :-) I decided to install the 47 dependencies and try to create the debian packages on the Sarge testing system. The freeradius I downloaded is: freeradius-snapshot-20030930 When I run the command: dpkg-buildpackage -us -uc -b -rfakeroot Here is the list of packages I had to install (YUCK!): binutils dpkg-dev make fakeroot autoconf autoconf2.13 autotools-dev comerr-dev cpp cpp-3.3 debconf-utils debhelper gcc gcc-3.3 gettext html2text intltool-debian libasn1-6-heimdal libc6-dev libcomerr1-kerberos4kth libecpg3 libgdbm-dev libiodbc2 libiodbc2-dev libkadm55 libkrb-1-kerberos4kth libkrb5-17-heimdal libkrb5-dev libkrb53 libldap2-dev libltdl3 libltdl3-dev libmysqlclient10-dev libpam0g-dev libpq3 libroken16-kerberos4kth libsasl2-dev libsnmp4.2 libsnmp4.2-dev libssl-dev libtool1.4 m4 po-debconf postgresql-dev snmp zlib1g-dev Is this enormous list a good enough reason to split the freeradius package into sub-packages? When it tries to build, it quits with this problem: [snip] Making static in rlm_eap_mschapv2... make[11]: Entering directory `/root/work/freeradius-snapshot-20030930/src/modules/rlm_eap/types/rlm_eap_mschapv2' gcc -Wall -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -g -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -W -Wredundant-decls -Wundef -I../../../../include -I../.. -c rlm_eap_mschapv2.c -o rlm_eap_mschapv2.o rlm_eap_mschapv2.c: In function `mschapv2_authenticate': rlm_eap_mschapv2.c:160: warning: unused parameter `arg' /usr/bin/libtool --mode=link ld \ -module -static -Wall -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -g -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -W -Wredundant-decls -Wundef -I../../../../include -I../.. rlm_eap_mschapv2.o eap_mschapv2.o -o rlm_eap_mschapv2.a mkdir .libs (cd . && ln -s eap_mschapv2.lo eap_mschapv2.o) ar cru rlm_eap_mschapv2.a rlm_eap_mschapv2.o eap_mschapv2.o ar: eap_mschapv2.o: No such file or directory make[11]: *** [rlm_eap_mschapv2.a] Error 1 make[11]: Leaving directory `/root/work/freeradius-snapshot-20030930/src/modules/rlm_eap/types/rlm_eap_mschapv2' make[10]: *** [common] Error 1 make[10]: Leaving directory `/root/work/freeradius-snapshot-20030930/src/modules/rlm_eap/types' make[9]: *** [static] Error 2 make[9]: Leaving directory `/root/work/freeradius-snapshot-20030930/src/modules/rlm_eap/types' make[8]: *** [common] Error 1 make[8]: Leaving directory `/root/work/freeradius-snapshot-20030930/src/modules/rlm_eap' make[7]: *** [static] Error 2 make[7]: Leaving directory `/root/work/freeradius-snapshot-20030930/src/modules/rlm_eap' make[6]: *** [common] Error 1 make[6]: Leaving directory `/root/work/freeradius-snapshot-20030930/src/modules' make[5]: *** [all] Error 2 make[5]: Leaving directory `/root/work/freeradius-snapshot-20030930/src/modules' make[4]: *** [common] Error 1 make[4]: Leaving directory `/root/work/freeradius-snapshot-20030930/src' make[3]: *** [all] Error 2 make[3]: Leaving directory `/root/work/freeradius-snapshot-20030930/src' make[2]: *** [common] Error 1 make[2]: Leaving directory `/root/work/freeradius-snapshot-20030930' make[1]: *** [all] Error 2 make[1]: Leaving directory `/root/work/freeradius-snapshot-20030930' make: *** [build-simple] Error 2 ~/work/freeradius-snapshot-20030930# ls -al src/modules/rlm_eap/types/rlm_eap_mschapv2/ total 132 drwxr-xr-x4 507 postfix 4096 Sep 30 14:43 . drwxr-xr-x8 507 postfix 4096 Sep 30 04:00 .. drwxr-xr-x2 root root 4096 Sep 30 14:43 .libs drwxr-xr-x2 507 postfix 4096 Sep 30 04:00 CVS -rw-r--r--1 root root 317 Sep 30 14:43 Makefile -rw-r--r--1 507 postfix 256 Sep 19 14:19 Makefile.in -rw-r--r--1 root root 218 Sep 30 14:43 config.log -rwxr-xr-x1 root root 6119 Sep 30 14:43 config.status -rwxr-xr-x1 507 postfix 31138 Sep 29 10:04 configure -rw-r--r--1 507 postfix 949 Sep 19 14:19 configure.in -rw-r--r--1 507 postfix 518 Sep 19 14:19 eap_mschapv2.h lrwxrwxrwx1 root root 15 Sep 30 14:43 eap_mschapv2.o -> eap_mschapv2.lo -rw-r--r--1 507 postfix 7723 Sep 19 14:19 rlm_eap_mschapv2.c -rw-r--r--1 root root46580 Sep 30 14:43 rlm_eap_mschapv2.o ~/work/freeradius-snapshot-20030930# ls -al src/modules/rlm_eap/types/rlm_eap_mschapv2/.libs/ total 8 drwxr-xr-x2 root root 4096 Sep 30
RE: Installing Freeradius on Debian
> From: Nick Davis > Sent: Wednesday, 1 October 2003 3:34 AM > > > I am building the debian package on a debian Woody stable system and am > > > going to copy it over to a debian Sarge testing system. > > Wild. Any reason you're not building it on a testing system? I'd offer to > > do so, but my testing machine is also PowerPC, and so the packages probably > > aren't a lot of use to you. :-) > I only have one system running testing and that is already setup to be a > production server. I do not want to install any *dev or compiling packages on > there. I figured that it would work fine if I build the packages on Woody and > then installed them on Sarge. Sarge should have all of the required packages, > but newer versions. So, it should still work. If I'm wrong on that > assumption, please let me know! Beats me. We can hope, I guess. :-) You might find that building on unstable is also viable right now, testing's fairly up to date. > > > I found the instructions Paul H. wrote below along with his other post > > > that has the patch to take iodbc out of the main freeradius package. I > > > applied that patch with little trouble, and am now to the instructions in > > > the email below. > > > > I'm still fielding good reasons to include that patch in the main package. > > :-) There're concerns about package-list-bloat, and I've yet to come up > > with a convincing argument that overrides that. > > I noticed while applying the patch was that it split iodbc out into it's own > package, but didn't split out postgres, mysql, and ldap. If you are going to Huh? It should... That's _why_ IODBC's the prime candidate, since the _other_ databases that are built are split out already. > split out one, you should split them all (or at least most) out of the main > package. Yes, I know that patch was only to split out iodbc, I'm just saying > we should do an all or none scheme. A good way to do that would be to ask > this question "Is there more than one module that does a similar job as this > module I am looking at?" If yes, split out those modules into their own > packages. If not, leave it as part of the main package. So, if you were > looking at mysql, you would answer yes. Then you would split out mysql, > postgresql, iodbc, and whatever other database modules there are. > If you look at other server software that has a whole slew of modules, you > will see many modules are broken out into their own packages. Examples: > apache, php, mysql, postfix, perl > So, lets add freeradius to that list. It will make the base package simpler. > So, when a person wants to use a module they just grab the package containing > said module. The other candidates are rlm_unix (for shadow group membership) and... I dunno. I'm sure I had others, but I can't for the life of me remember. Unixodbc was discussed, but it's a pain to build since I think iodbc-dev and unixodbc-dev can't be installed at the same time. > Here is another thought: If you break out the modules into separate packages, > on installation of the main package you could present the user with a short > menu to select which modules they would like to install. If they are > installing in the debian mode where it doesn't ask the user for any input, > just assume they selected all of them. Arrgh. It would be the other way 'round, in fact. Headless install should do just what the user asks. Either way, I think that's abuse of debconf and the package management system as a whole. I would annoy aptitude users and people installing with dpkg, off the top of my head. > My $0.02 towards that argument:) > > > Here is the list I get: > > > dpkg-checkbuilddeps: Unmet build dependencies: libltdl3-dev, > > > libpam0g-dev, postgresql-dev, libgdbm-dev | libgdbmg1-dev, libldap2-dev, > > > libsasl2-dev, libiodbc2-dev, libkrb5-dev > > > > > > I do not plan to use kerberos, ldap,nor postgres and I'm not so sure that > > > I need libgdmg1 either. I use mysql for everything except the > > > dictionaries. > > > > > > My question is: how can I remove some of the build dependencies for > > > packages that I do not intent to use? > > > > libpam0g-dev is used by rlm_pam > > > > libgbmg1 is used by rlm_counter, rlm_gdbm and rlm_ippool > > > > postgresql-dev is for rlm_sql_postgresql > > > > libldap2-dev and libsasl2-dev are for rlm_ldap > > > > libiodbc2-dev is for rlm_sql_iodbc > > Why would this still be here if I already applied the iodbc patch? Because it splits out the resulting package, but it still builds those modules Aaah! Now your earlier comment makes sense. What we're doing here is splitting the resulting package files so that the target server doesn't gain library dependancies which are unnecessary for that installation. It still _builds_ all the modules. It's just when it assembles the modules into packages that the list matters. > > libkrb5-dev is for rlm_krb5 > > > > None of these build-dependancies are for the core daemon. I left off de
Re: Installing Freeradius on Debian
> > I have been using freeradius since 0.3 installed from source and I wanted > > to give the debian package a try. I did not see a freeradius package in > > unstable nor testing. Is freeradius still changing too fast for debian? > > Not anymore, I feel. The prospective Debian packaging of 0.9.1 is with the > prospective sponsor, so hopefully in time for Sarge's release... Lets hope so! I'll just have to get my own .deb package to build for now then. > > I am building the debian package on a debian Woody stable system and am > > going to copy it over to a debian Sarge testing system. > > Wild. Any reason you're not building it on a testing system? I'd offer to > do so, but my testing machine is also PowerPC, and so the packages probably > aren't a lot of use to you. :-) I only have one system running testing and that is already setup to be a production server. I do not want to install any *dev or compiling packages on there. I figured that it would work fine if I build the packages on Woody and then installed them on Sarge. Sarge should have all of the required packages, but newer versions. So, it should still work. If I'm wrong on that assumption, please let me know! > > I found the instructions Paul H. wrote below along with his other post > > that has the patch to take iodbc out of the main freeradius package. I > > applied that patch with little trouble, and am now to the instructions in > > the email below. > > I'm still fielding good reasons to include that patch in the main package. > :-) There're concerns about package-list-bloat, and I've yet to come up > with a convincing argument that overrides that. I noticed while applying the patch was that it split iodbc out into it's own package, but didn't split out postgres, mysql, and ldap. If you are going to split out one, you should split them all (or at least most) out of the main package. Yes, I know that patch was only to split out iodbc, I'm just saying we should do an all or none scheme. A good way to do that would be to ask this question "Is there more than one module that does a similar job as this module I am looking at?" If yes, split out those modules into their own packages. If not, leave it as part of the main package. So, if you were looking at mysql, you would answer yes. Then you would split out mysql, postgresql, iodbc, and whatever other database modules there are. If you look at other server software that has a whole slew of modules, you will see many modules are broken out into their own packages. Examples: apache, php, mysql, postfix, perl So, lets add freeradius to that list. It will make the base package simpler. So, when a person wants to use a module they just grab the package containing said module. Here is another thought: If you break out the modules into separate packages, on installation of the main package you could present the user with a short menu to select which modules they would like to install. If they are installing in the debian mode where it doesn't ask the user for any input, just assume they selected all of them. My $0.02 towards that argument:) > > Here is the list I get: > > dpkg-checkbuilddeps: Unmet build dependencies: libltdl3-dev, > > libpam0g-dev, postgresql-dev, libgdbm-dev | libgdbmg1-dev, libldap2-dev, > > libsasl2-dev, libiodbc2-dev, libkrb5-dev > > > > I do not plan to use kerberos, ldap,nor postgres and I'm not so sure that > > I need libgdmg1 either. I use mysql for everything except the > > dictionaries. > > > > My question is: how can I remove some of the build dependencies for > > packages that I do not intent to use? > > libpam0g-dev is used by rlm_pam > > libgbmg1 is used by rlm_counter, rlm_gdbm and rlm_ippool > > postgresql-dev is for rlm_sql_postgresql > > libldap2-dev and libsasl2-dev are for rlm_ldap > > libiodbc2-dev is for rlm_sql_iodbc Why would this still be here if I already applied the iodbc patch? > libkrb5-dev is for rlm_krb5 > > None of these build-dependancies are for the core daemon. > > The way I'd do it is remove those modules from the 'stable' file in > src/modules or src/modules/rlm_sql/ depending on which modules they are. > This step is basically optional, since it should skip that which it can't > build. > > Then remove the entries for those things from debian/rules in the various > 'for each' clauses. And remove the entries from the debian/control file. > (ie. the opposite of the freeradius-iodbc patch you've already got. :-) > > Then remove the build-dependancies that trouble you so. Wow, what a pain in my behind! I can't wait for prebuilt debian packages. > You'll need that libltdl3-dev, however. No way around it except building > statically, and I dunno what that does to the build-dependancies, or the > rlm_sql and rlm_eap modules. Good to know thanks! Nick -- Nick Davis Associate Systems Administrator [EMAIL PROTECTED] Internet Exposure, Inc. http://www.iexposure.com (612)676-1946 Web Development-Web Marketing-ISP
RE: Installing Freeradius on Debian
> From: Nick Davis > Sent: Friday, 26 September 2003 7:57 AM > I have been using freeradius since 0.3 installed from source and I wanted to > give the debian package a try. I did not see a freeradius package in unstable > nor testing. Is freeradius still changing too fast for debian? Not anymore, I feel. The prospective Debian packaging of 0.9.1 is with the prospective sponsor, so hopefully in time for Sarge's release... > I am building the debian package on a debian Woody stable system and am going > to copy it over to a debian Sarge testing system. Wild. Any reason you're not building it on a testing system? I'd offer to do so, but my testing machine is also PowerPC, and so the packages probably aren't a lot of use to you. :-) > The freeradius I downloaded is: freeradius-snapshot-20030925 > > I found the instructions Paul H. wrote below along with his other post that > has the patch to take iodbc out of the main freeradius package. I applied > that patch with little trouble, and am now to the instructions in the email > below. I'm still fielding good reasons to include that patch in the main package. :-) There're concerns about package-list-bloat, and I've yet to come up with a convincing argument that overrides that. > When I run the command: > dpkg-buildpackage -us -uc -b -rfakeroot > > I get a list of missing build dependencies like I am supposed to. > > Here is the list I get: > dpkg-checkbuilddeps: Unmet build dependencies: libltdl3-dev, libpam0g-dev, > postgresql-dev, libgdbm-dev | libgdbmg1-dev, libldap2-dev, libsasl2-dev, > libiodbc2-dev, libkrb5-dev > > I do not plan to use kerberos, ldap,nor postgres and I'm not so sure that I > need libgdmg1 either. I use mysql for everything except the dictionaries. > > My question is: how can I remove some of the build dependencies for packages > that I do not intent to use? libpam0g-dev is used by rlm_pam libgbmg1 is used by rlm_counter, rlm_gdbm and rlm_ippool postgresql-dev is for rlm_sql_postgresql libldap2-dev and libsasl2-dev are for rlm_ldap libiodbc2-dev is for rlm_sql_iodbc libkrb5-dev is for rlm_krb5 None of these build-dependancies are for the core daemon. The way I'd do it is remove those modules from the 'stable' file in src/modules or src/modules/rlm_sql/ depending on which modules they are. This step is basically optional, since it should skip that which it can't build. Then remove the entries for those things from debian/rules in the various 'for each' clauses. And remove the entries from the debian/control file. (ie. the opposite of the freeradius-iodbc patch you've already got. :-) Then remove the build-dependancies that trouble you so. You'll need that libltdl3-dev, however. No way around it except building statically, and I dunno what that does to the build-dependancies, or the rlm_sql and rlm_eap modules. -- = Paul "TBBle" Hampson Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] On a sidewalk near Portland State University someone wrote `Trust Jesus', and someone else wrote `But Cut the Cards'. - Random signature generator 3.0 by Paul "TBBle" Hampson = - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Installing Freeradius on Debian
I have been using freeradius since 0.3 installed from source and I wanted to give the debian package a try. I did not see a freeradius package in unstable nor testing. Is freeradius still changing too fast for debian? I am building the debian package on a debian Woody stable system and am going to copy it over to a debian Sarge testing system. The freeradius I downloaded is: freeradius-snapshot-20030925 I found the instructions Paul H. wrote below along with his other post that has the patch to take iodbc out of the main freeradius package. I applied that patch with little trouble, and am now to the instructions in the email below. When I run the command: dpkg-buildpackage -us -uc -b -rfakeroot I get a list of missing build dependencies like I am supposed to. Here is the list I get: dpkg-checkbuilddeps: Unmet build dependencies: libltdl3-dev, libpam0g-dev, postgresql-dev, libgdbm-dev | libgdbmg1-dev, libldap2-dev, libsasl2-dev, libiodbc2-dev, libkrb5-dev I do not plan to use kerberos, ldap,nor postgres and I'm not so sure that I need libgdmg1 either. I use mysql for everything except the dictionaries. My question is: how can I remove some of the build dependencies for packages that I do not intent to use? Is there a better way to do this now? Thanks! Nick On Friday 04 July 2003 01:35, Paul Hampson wrote: > > From: Aime > > Sent: Friday, 4 July 2003 1:27 AM > > > > Where can i find a step-by-step to install Freeradius > > on Debian ? > > > > - Packages that needs to be in place. > > - best way to proceed > > - etc... > > I dunno if there's one written, but here's what I do: > > Grab current CVS snapshot (or wait for 0.9) > Extract tarball. > Go into the directory, and run > dpkg-buildpackage -us -uc -b -rfakeroot > It should tell you what packages you're missing... > If you're on Debian woody or Debian testing, you may > be unable to fufill both libsasl2-dev and libopneldap-dev > dependancies, so remove the '2' from the libsasl2-dev > dependancy. > Again run dpkg-buildpackage -us -uc -b -rfakeroot and > you should get .debs in the directory above the current. > > That's basically it. > > I'm hoping that 0.9 will actually be part of Debian, so > even this won't be neccessary unless you need something > from CVS. > > -- > = > Paul "TBBle" Hampson > Bubblesworth Pty Ltd (ABN: 51 095 284 361) > [EMAIL PROTECTED] > -- Nick Davis Associate Systems Administrator [EMAIL PROTECTED] Internet Exposure, Inc. http://www.iexposure.com (612)676-1946 Web Development-Web Marketing-ISP Services - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Installing Freeradius on Debian
> From: Aime > Sent: Friday, 4 July 2003 1:27 AM > Where can i find a step-by-step to install Freeradius > on Debian ? > - Packages that needs to be in place. > - best way to proceed > - etc... I dunno if there's one written, but here's what I do: Grab current CVS snapshot (or wait for 0.9) Extract tarball. Go into the directory, and run dpkg-buildpackage -us -uc -b -rfakeroot It should tell you what packages you're missing... If you're on Debian woody or Debian testing, you may be unable to fufill both libsasl2-dev and libopneldap-dev dependancies, so remove the '2' from the libsasl2-dev dependancy. Again run dpkg-buildpackage -us -uc -b -rfakeroot and you should get .debs in the directory above the current. That's basically it. I'm hoping that 0.9 will actually be part of Debian, so even this won't be neccessary unless you need something from CVS. -- = Paul "TBBle" Hampson Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] This is a one line proof...if we start sufficiently far to the left. -- Cambridge University Math Department - Random signature generator 3.0 by Paul "TBBle" Hampson = - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
