[sle-beta] Beta3 post install software installation

[Joe Doupnik]

     Addendum to the msg below, dealing with YaST this time.
     On the "second" machine built without adjustments, after taking a 
VMware snapshot I have asked YaST to install Openssl v1.1. Selecting 
just libopenssl1_1_0 worked, but while there adding either (or both) 
openssl-1_1_0 or libopenssl-1_1_0-devel produces a conflict message from 
YaST where it requires one to remove the present v1.0.2l files and 
remove pesign-obs-integration. That's the part of the problem.
     YaST should allow libopenssl1_1_0 to enter without complaint as 
there is no conflict. When the -devel material is added then it should 
offer to remove only the existing/conflicting -devel RPM. That way one 
can flip flop -devel's to build as desired. Futzing with the libssl.so 
symlink is another weak link in the chain and that should be handled 
more gracefully than at present.
     Thus at this moment in affairs openssl v1.1 is a no-go item in 
SLES. Golly, we need a Security channel again to have selected apps 
which are built for v1.1. Right, just what you wanted to hear. Sorry 
about that.
     Thanks,
     Joe D.

On 29/11/2017 19:21, Joe Doupnik wrote:
> 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
>
> _______________________________________________
> sle-beta mailing list
> sle-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sle-beta