pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-users] SSL not supported?


From: Mike Brown
Subject: Re: [Pan-users] SSL not supported?
Date: Thu, 21 Jun 2012 04:19:09 -0500
User-agent: Mutt/1.5.17 (2007-11-01)

On Thu, Jun 21, 2012 at 08:56:21AM +0000, Duncan wrote:
> 
> The readme file lists the packages as shipped by upstream.  It's the 
> binary distros that are splitting lib packages in half, into runtime and 
> devel pieces, since that allows most users, the binary-only users who 
> never build anything depending on that package, to skip a number of extra 
> files (in addition to the *.pc file, there's the header files, etc, and 
> sometimes developer documentation).

Having separate dev and runtime installs has been around for ages.  Solaris
does the same thing.  I was born and bred under BSD4.x on a Dec Vax 11/750.
Yep, that goes way back.  We even had a 32V source license. :-)

> The readme is therefore simply expecting users to be familiar with the 
> normal build process on their distro, which for many binary-based-
> distros, means installing the devel half of dependencies.

In this case, installing both pieces didn't work.

> Yum certainly wouldn't do the trick either.  While a lot of distros use 
> yum, it's really distro-specific, while libraries are normally distro 
> independent, sometimes only shipping in sources form, to be packaged by 
> the distros that want them.

Fedora is yum based for updates.  But, it isn't yum that creates the file
for pkg-config to find.  That is the responsibility of those who create the
RPMs.  It seems to me that a "package".pc file is not a requirement.  As
such, pkg-config should not be used to find installed files.  We got along
for decades with pkg-config, why start now?

> Do be aware that while SSL in general works, being the new (and 
> relatively complex) feature it is, it doesn't have anything NEAR the 
> history or DECADES of actual use by all sorts of people against all sorts 
> of servers, that the plain-text connection code does.  As such, it does 
> still have issues in certain cases.  Just because it's available doesn't 
> mean it's guaranteed to work on your hardware connected to your server.

I'll keep that in mind.  I need to update to at least F16 anyway.  While the
Linux box is not directly probeable from the net (the Solaris server it is
replacing is), the need for security updates is not a must.  I've found that
it was a good thing that I procrastinated putting it on line as the new server,
as making the Linux box do a little bit of work, i.e., using pan to download
files, tends to cause the unit to just quit, as if someone pulled the power
cord.  Just sitting there running, browsing at most, never caused it to fail.
It isn't the OS, as there is no warning.  The amount of time between power
fails varies, a lot.

So, I want to at least get it up-to-date before digging into the power failure
even more.

> IOW, with a newer pan built with SSL support, it'll /probably/ work just 
> fine for you , but...  It'd just be a shame to have you do the upgrade in 
> ordered to get a pan that supports SSL, only to have it not work for you 
> because your provider does something weird with the SSL connection that 
> doesn't work with pan's SSL code just yet.  Just a risk to be aware of 
> with the new SSL code, before you go to all that trouble, just in case...

See above regarding the update.  I'm currently at least 2 OS versions
out-of-date, with F17 just recently being released.  I'm not sure yet if I
am going to go with mate or cinnamon.  AFAIK, I can't go to F17 until mate
and/or cinnamon are updated for F17.

But, I'll keep in mind that SSL might not work.  And if not, maybe I can
supply info that will help getting it fixed.  Of course, that will probably
require doing a compile with debug enabled and right now, compiling doesn't
work. :-(

MB
-- 
e-mail: address@hidden | address@hidden            /~\ The ASCII
        address@hidden (140 char limit)       \ / Ribbon Campaign
Visit - URL: http://vidiot.com/                           X  Against
             http://vidiot.net/                          / \ HTML Email



reply via email to

[Prev in Thread] Current Thread [Next in Thread]