[sle-beta] Beta3 post install software installation

[Joe Doupnik]

     Here is a quick and only preliminary report about the SSL problem 
which I reported a few days ago (included below).
     Two Beta 3 servers were built. One having OpenSSL v1.1 added and 
experiencing problems, the second working.
     Inspection of /usr/lib64/libssl* shows the first (problem) server 
has "libssl.so" symlinked to libssl.so.1.1. On the second server the 
symlink is to libssl.so.1.0.0. Moments ago I manually shifted the 
symlink on the first server to libssl.so.1.0.0 (which is present), 
rebooted the machine, and did a quick zypper lu command. That failed 
with the certificate errors. On the first machine zipper lu does work.
     Next I visited /etc/ssl on both machines. On the first, as noted 
below, it was basically empty. On the second there are entries 
ca-bundle.pem (which ought not appear there), certs (symlinked to 
/var/lib/ca-certificates/pem, which is a mess), and private (empty). 
This is markedly different than on previous SLES editions, and it is a 
bit of a shambles.
     On my main SLES11 server I have Openssl v0.9.8 and v1.0.1g, and 
both cohabit peacefully. I add or remove the -devel rpm to support the 
proper kind when building apps.
     What I deduce thus far is asking to have Openssl v1.1 cohabit with 
v1.0.2 results in moving the main library symlink (libssl.so) to  v1.1 
(which is not what I asked it to do), and the installation process 
became confused and decided to not even create the certificate store 
(even if in that wrong place of /var/lib for gosh sakes). No certs, no 
service, as we might say. Populating the "private" directory with my 
formal certs failed with a no CA Cert error popup which we can now 
understand that from the flinging of what was in /etc/ssl/certs  into 
instead the distant /var/lib swamp (so, if doing that then why bother 
with having an /etc/ssl directory?).
     In my view, the /etc/ssl construction prior to SLES15 is superior, 
clear, manageable, and what we have wired into our applications. Putting 
things in /var/lib is not good. Then, relying on (changing) symlinks in 
/etc/ssl is to further confuse an important area.  The YaST/installation 
part of things needs attention. The prior construction of /etc/ssl is 
organized for managers of the machines, and /var/lib is a large 
collecting ground for much other "stuff." I recommend we return to the 
safe and sane way of storing certificates.
     Thanks,
     Joe D.


On 26/11/2017 16:04, Joe Doupnik wrote:
>     I have run into two problems just after installation of beta 3.
>     If I ask YaST to allow me to inspect and install further software 
> then the process blocks with a popup which reduces to curl being 
> unable to find the local issuer's SSL certificate, curl error 60. The 
> repositories are those on SUSE, straight from the installation process.
>     Directory /etc/ssl/private is empty, thus no self signed certs. 
> Adding my proper certs into /etc/ssl/servercerts, and symlinking 
> /etc/ssl/private to that same directory has not improved things. Then 
> looking more carefully at /etc/ssl I find a large vacuum where CA 
> certs ought to be, empty space populated by only a lonely file named 
> openssl.cnf.
>     Taking a space walk into that problem, I went into YaST | 
> Software, asked about "certificate", got a list of installed 
> candidates, chose ca-certificates, got a warning popup which says I 
> must uninstall openssl v1.1 and install v1.0.2l. Hmmm, I had thought 
> certificates were impervious to editions of openssl, being rather 
> separate operations, but now we see them glued together. Not what I 
> expected nor can use.
>     Not to be stopped by mere failures, I told YaST to use option 3, 
> break dependencies for the ca-certificates item. It responded with an 
> error popup which said it could not contact SUSE to do this chore. At 
> this point I have that "Catch-22" feeling. It starts with certificates 
> being absent, and matters slide downhill from there.
>     What might be acting in this case is I have selected to install 
> OpenSSL v1.1 rather than the default v1.0.2. The SSL selection part 
> also indicates awkwardness which needs attention. That is, YaST does 
> not wish to allow me to install the SSL libraries for both versions of 
> SSL, even though the libraries do cohabit on earlier SLES's. My normal 
> drill is install two libraries, then when building things install the 
> appropriate -devel version so that the desired SSL version headers are 
> used.
>     Tis a puzzle at this moment.
>     Thanks,
>     Joe D.
>
>
> _______________________________________________
> sle-beta mailing list
> sle-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sle-beta