[sle-beta] Beta3 post install software installation

[Joe Doupnik]

Thorsten and the group,
     Fair enough. What I am trying to do in this particular case is use 
Openssl v1.1 to support building an application, and see if existing 
apps could use it. The answer to the latter is typically no, of course, 
as they are built against v1.0.2, which is a situation similar to using 
the Security Channel of previous versions of SLES to supply a few key 
apps built with another version of SSL. Building my own code needs SSL 
v1.1 for checking matters, and that means both the library and the 
headers (-devel bundle).
   Where matters become sticky is adding the -devel material, where YaST 
decides that we must remove all of the earlier SSL material (thus the 
earlier library as well). I think that is a step too far in the 
dependency resolution problem, where there is conflict only about the 
-devel part. This seems to be readily curable by a script tweak or two.
     So far, the running of apps is indeed supported by symlink 
libssl.so and we can install multiple libssl's. I point the symlink at 
an active library. Building an application with other than the stock SSL 
runs into difficulties because adding a more recent SSL -devel part 
causes wider spread trouble.

     Next there are the certificates. Right now this seems to be a 
muddle. I have two Beta 3 machines set up, one with the choice of SSL 
v1.1 and the second with the stock SSL v1.0.x. The first has experienced 
the discussed problems, and the second does work reasonably well. The 
certificate blockage does seem to be a dependency criteria which I have 
not decoded.
     Here is a screen capture of one case: on the SSL v1.1 (first) 
machine.  In YaST ask to install the ca-certificates RPM material, and 
the conflict resolution screen shown below appears:

     It says that to obtain the CA cert material I also must remove SSL 
v1.1, for unknown reasons. The best that I can guess is there is some 
hidden agent which is built against SSL v1.0.x which wants to be a 
guardian of such certs and can't work with SSL v1.1.  Just where I would 
place my regular cert material is uncertain as there is no corresponding 
area in either /etc/ssl nor /var/lib. Note that for this report's tests 
I have pointed the libssl.so symlink at the SSL v1.0.x library, thusly:

Note the date stamp on that symlink as it shows I modified it yesterday 
for this test.

     Next, the software update error messages on the SSL v1.1 machine. 
Four screen captures.
     The first is visiting YaST Online Update:


     Skipping the Autorefresh produces this curl error 60 popup:


     Then if one issues command   zypper lu  the screen shows many lines 
such as this one:


or the same but in a terminal session in the GUI:


All are saying the CA cert is not available, which we know from the CA 
problem above, and indeed there is no CA cert area.

     From my vantage a couple of comments.
     First, have the usual CA bundle be present/installable, regardless 
of OpenSSL versions. That takes some detective work at the SUSE end to 
resolve. Then Curl, Apache, zypper et al would stand a chance of running 
against at minimum a self signed cert or more normally against a user 
supplied set. Swapping a symlink for development is the manager's choice.
     Second, the /etc/ssl grouping of cert material makes good sense. 
This goes against the unfortunate LSB grain of scattering things all 
over. The reason is to get at the certificate material (as we must these 
days) in a simple easy to remember fashion and avoid being tripped up by 
symlinks hiding elsewhere. It's usage in the field which is important, a 
people and management time concern.
     Thanks,
     Joe D.


On 29/11/2017 21:01, Thorsten Kukuk wrote:
> On Wed, Nov 29, Joe Doupnik wrote:
>
>>      In my view, the /etc/ssl construction prior to SLES15 is superior,
>> clear, manageable, and what we have wired into our applications.
> How can the /etc/ssl construct prior to SLES15 be superior if it is
> identical between SLES12 and SLES15?
>
> Maybe you should start at first in your bug reports with what you are
> exactly doing and what the exact error messages are? Beside that it is
> not working on one machine for you, there is not much we can use to
> identify the root cause.
> Start for example with the error message of update-ca-certifiates.
>
> Beside that, if changing the libssl.so symlink makes a different for you,
> that you have some broken third party RPMs flying around somewhere.
> libssl.so is only used for linking applications, it should never be
> needed at runtime. If you have applications which needs this link at
> runtime, you have lost. This will never work stable.
> And libssl.so is coming with a *-devel RPM. And the *.so symlink has
> to match exactly the header files, else compiling and linking will
> never work, too. If you have the wrong *-devel package installed,
> you should deinstall it and install the right one, not changing
> symlinks.
>
>    Thorsten
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.suse.com/pipermail/sle-beta/attachments/20171130/f6a65854/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jhmfcdkkfgbdjdae.png
Type: image/png
Size: 92119 bytes
Desc: not available
URL: <http://lists.suse.com/pipermail/sle-beta/attachments/20171130/f6a65854/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cgjiadnccjlmeloo.png
Type: image/png
Size: 18939 bytes
Desc: not available
URL: <http://lists.suse.com/pipermail/sle-beta/attachments/20171130/f6a65854/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pggnlmpbgkopfjka.png
Type: image/png
Size: 86713 bytes
Desc: not available
URL: <http://lists.suse.com/pipermail/sle-beta/attachments/20171130/f6a65854/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ghjikemaahkcddkm.png
Type: image/png
Size: 26439 bytes
Desc: not available
URL: <http://lists.suse.com/pipermail/sle-beta/attachments/20171130/f6a65854/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pfnmldjnhobdiife.png
Type: image/png
Size: 33587 bytes
Desc: not available
URL: <http://lists.suse.com/pipermail/sle-beta/attachments/20171130/f6a65854/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jeaopfgmbejchand.png
Type: image/png
Size: 111122 bytes
Desc: not available
URL: <http://lists.suse.com/pipermail/sle-beta/attachments/20171130/f6a65854/attachment-0005.png>