[sle-beta] Beta3 post install software installation
jrd at netlab1.net
Wed Nov 29 12:21:27 MST 2017
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.
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
> 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
> Tis a puzzle at this moment.
> Joe D.
> sle-beta mailing list
> sle-beta at lists.suse.com
More information about the sle-beta