[csw-maintainers] Feedback requested for FreeRADIUS

Geoff Davis gadavis at opencsw.org
Tue Dec 7 04:09:14 CET 2010


Hi all,

I went to try and use FreeRADIUS the other day and noticed that it was really out of date, and missing any sort of capability to interface with OpenLDAP. After battling with various compiler options, and some really weird hybrid of GNU autoconf and legacy makefiles, I have a workable 32-bit package, less the init script. 

In an attempt to keep the amount of dependencies of the main package to a minimum, I've split out two modules currently - krb5 and ldap. I'm having some issues getting some of the various other modules to compile due to the really odd Makefile system in use by this package. Up to now the only module that users have requested is "rlm_ldap" (Mantis 2222, 4110), and luckily that is compiling just fine right now.

I've never really worked with FreeRADIUS before, so I'm flying blind on a lot of this package. As this is a rather complex software suite with a number of modules and myriad configuration options, I would appreciate some additional eyes on it. 

Here are some questions that I have:
1. Should I try to get radiusd to work as another user other than root?
I know that OpenLDAP runs as root, but other packages like dovecot do not.

2. Should I try to split out the devel files?
There aren't too many include files, especially compared to the data files (aka RADIUS dictionaries). Also splitting out the devel files causes some package conflicts with some bare .so symlinks included as convience links for using the modules. For example, each module is named rlm_foo-2.1.10.so (yes the version number comes before the ".so") and has a symlink included with it called rlm-foo.so. Nobody will be linking to the modules directly, and the rlm-foo.so symlinks merely exist for convenience in the configuration of radiusd. I can't figure out how to exclude any symlink named rlm-foo.so from PKGFILES_DEVEL.

3. Should I try to split out the FreeRADIUS dictionaries?
They are required for radiusd to run so they wouldn't be an optional install. They potentially could be an archall package, but I'm not sure if I'm just making extra packages for the sake of making packages. There are a lot of them however.

4. Is it worth splitting out all of the documentation from the main package? 
4a. If so, where do I put the documentation that pertains to the few modules that I've split out?
4b. Should the man pages stay with the main package or go into the doc package?

Thanks,
Geoff


More information about the maintainers mailing list