eap/tls freeradius openssl

[Craig White]

On Tue, 2009-01-13 at 13:33 -0500, John Dennis wrote:
> Craig White wrote: 
> > On Tue, 2009-01-13 at 11:46 -0500, John Dennis wrote:
> >   
> > > Brian Ertel wrote:
> > >     
> > > > John,
> > > > 
> > > > You are right, but the dir where the old radius was "make installed" is
> > > > gone.  That is the original folder that was created after unzipping and
> > > > installing the old ver. Of radius is gone.  Is there anything else I can do?
> > > >   
> > > >       
> > > You can recreate the tree, follow the same steps you did the first time 
> > > which was probably something like this:
> > > 
> > > % tar xf freeradius-server.tar
> > > % cd freeradius-server
> > > % ./configure #passing the exact same parameters you used the first time
> > > % make
> > > 
> > > Now instead of "make install" run make "make uninstall"
> > > 
> > > Then you can delete the source tree.
> > > 
> > > BTW, all this is basic Linux/Unix administration, the freeradius-users 
> > > list is not an appropriate place to learn these topics.
> > >     
> > ----
> > seems to me that it attempts to load the files he installed from tarball
> > that are in /usr/local/[bin|sbin] and that is what he needs to clean out
> > before he ever attempts to use anything installed from rpm
> >   
> Exactly. FWIW the paths are embedded as a consequence of parameters
> passed to configure. When you build from an SRPM the spec file passes
> different parameters to configure than the default configure
> parameters, thus the two installs will not likely conflict, but it's
> possible. Therefore the best course of action, to assure there are no
> conflicts and to reduce the inevitable confusion of having multiple
> copies installed in various locations is to remove the first
> installation and then do an RPM install.
> 
> An install copies many files into a variety of locations, the only way
> to assure you've removed all the files to use the same code to
> uninstall as was used to perform the install in the first place.
> 
> BTW, this is one reason why using the package manager on the target
> system (e.g. rpm, apt, dpkg, etc.) is always preferred because they
> know how to install and uninstall and keep a system consistent. When
> you go behind the back of these package managers by installing things
> manually (e.g. make install) you run the risk of screwing your system
> up unless you have advanced skills and know exactly what you're doing.
----
and 'make uninstall' often is simply not implemented in tarballs anyway.

Seeing the OP trying to install tarballs and rpm packages seems to be a
lesson in futility and I always opt for rpms if at all possible, just
for the reasons that you mentioned.

I actually rebuilt the F10 rpms before I saw your wiki page and like
about the day before you announced the 2.1.3 package in testing so I'm
sorry I didn't provide any useful feedback to either.

Craig